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笔者 从 研究 生 学 习 期 间 开始 接触 Linux 内 核 至 今 已 十 年 有 余 ， 直 到 现在 仍然 在 研读 各 种 
内 核 书籍 ， 细 读 之 后 始终 有 一 些 疑 问 和 困惑 。Linux 内 核 的 需求 从 何 而 来 ， 是 怎样 的 需求 ? 
Linux 内 核 的 层次 结构 是 怎样 的 ? 每 个 功能 模块 是 如 何 划 分 的 ?为 什么 要 这 么 设计 ? 多 种 设 
备 及 驱动 应 该 如 何 划 分 ， 划 分 的 依据 是 什么 ”设备 模型 究竟 是 怎么 回 事 ” 电源 管理 技术 是 如 
何 实现 的 ? 处 理 器 与 Linux 内 核 之 间 的 功能 关系 是 怎样 的 ? 本 书 就 是 建立 在 对 这 些 问题 的 思 
考 和 解答 基础 上 的 ， 读 者 可 以 在 阅读 本 书 的 过 程 中 找到 这 些 问 题 的 答案 。 这 些 问 题 的 解答 对 
于 各 种 层次 的 开发 者 来 说 都 是 需要 的 ， 一 方面 ， 可 以 加 深 开 发 者 对 于 系统 的 理解 ， 做 到 明 其 
理 的 程度 ; 另 一 方面 ， 从 需求 出 发 也 符合 对 事物 理解 的 规律 ， 可 加 深 对 系统 的 认识 。 

笔者 有 幸 于 2003 年 加 入 开 开 始 艇 人 式 处 理 器 开发 之 旅 。TI 开放 的 文化 使 笔者 有 很 多 机 
会 了 解 芯片 的 先进 技术 ， 开 完备 的 开发 文档 使 笔者 可 以 了 解 各 种 实现 细节 ， 从 而 不 断 地 成 
长 。 在 进行 了 大 量 的 代码 注释 工作 后 ， 笔 者 终于 解答 了 之 前 的 问题 ， 从 而 写 出 了 本 书 。 

本 书 在 结构 编排 上 ， 从 基础 出 发 ， 使 各 章节 相对 独立 ， 但 是 少量 的 向 前 或 者 向 后 引用 还 
是 必 不 可 少 的 。 总 体 上 ， 本 书 是 将 最 基本 的 章节 尽量 放 到 前 面 ， 所 以 推荐 按 顺 序 阅 读 。 

在 代码 的 引用 上 ， 以 TI 发布 的 DM 3730 的 Android 版 本 中 内 核 代 码 为 主 ， 为 了 突出 主 
线 部 分 和 削减 本 书 的 篇 幅 ， 笔 者 以 核心 功能 代码 为 主 进 行 分 析 和 介绍 ， 而 省 略 了 辅助 型 代 
码 。 内 核 的 代码 是 不 断 演进 的 ， 如 果 掌 握 了 书 中 分 析 代 码 的 思路 ， 那 么 读者 自己 来 对 新 版 本 
的 内 核 进行 理解 也 不 是 不 可 能 的 。 因 为 笔者 水 平 所 限 ， 加 之 Linux 内 核 本 身 就 博大 精深 ， 所 
以 书 中 肯定 还 会 有 一 些 错 误 ， 和 希望 读者 朋友 们 能 不 音 批 评 指 正 ， 以 使 大 家 可 以 共同 提高 。 

读者 如 果 在 阅读 本 书 的 过 程 中 有 任何 意见 或 者 建议 ， 欢 迎 通 过 下 面 的 上 上 -mail 与 笔者 取 
得 联系 : donglfeng@ sina. com。 关 于 本 书 使 用 到 的 源 代码 ， 读 者 可 在 TE 网 站 上 获取 。 

在 本 书写 作 过 程 中 ， 父 母 和 妻子 给 予 了 我 很 多 生活 上 及 精神 上 的 支持 ， 妻 子 还 主动 承担 
了 校对 的 工作 ， 谨 以 此 书 献 给 他 们 。 另 外 特别 提 到 岳父 和 岳母 ， 是 他 们 在 女儿 两 岁 前 悉心 的 
照料 ， 使 得 我 拥有 独立 而 充足 的 时 间 进 行 学 习 和 研究 ， 在 此 表示 由 更 的 感谢 。 感 谢 宝贝 女儿 
花生 ， 她 的 出 生 带 来 很 多 欢乐 ， 也 是 我 写作 的 动力 之 源 。 

还 要 感谢 机 械 工 业 出 版 社 的 时 静 编 辑 ， 从 选 题 的 论证 到 文字 编辑 ， 他 都 付出 了 极其 注音 
的 劳动 并 且 提 出 了 很 多 有 益 的 建议 。 

最 后 要 感谢 在 TI 遇 到 的 兄弟 姐妹 们 ， 用 这 本 书 来 纪念 我 们 一 起 战斗 的 日 日 夜 夜 。 
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1.1. 为 什么 要 从 硬件 设备 的 角度 看 Linux 内 核 


Linux 内 核 作为 目前 最 成 功 以 及 发 展 最 快 的 开源 项 目 之 一 ， 在 实际 应 用 中 取得 的 巨大 成 
功 是 举世 有 瞩 目的。 对 庞大 的 Linux 内 核 ， 大 家 是 否 有 如 下 的 疑问 : 究竟 是 哪些 组 织 和 个 人 为 
它 的 实现 做 出 了 贡献 呢 ? 又 分 别 做 出 了 多 大 的 贡献 呢 ? 

Linux Foundation 于 2013 年 9 月 发 布 了 《Who Writes Linux) 报告 公布 了 最 新 的 不 同 组 
织 对 Linux 内 核 贡 献 的 情况 ， 见 表 1-1。 


表 1-1 不 同 组 织 对 Linux 内 核 贡 献 




























































































ds 司 修改 次 数 | A 分 比 A 司 修改 次 数 | 百分比 
None 12 ,550 13.60% — || NVidia 1,192 1. 30% 
Red Hat 9,483 10.20% || Freescale 1,127 1. 20% 
Intel 8,108 8. 80% Ingics Technology 1,075 1. 20% 
Texas Instruments 3,814 4. 10% Renesas Electronics 1,010 1. 1096 
Linaro 3,791 4. 10% Qualcomm 965 1. 00% 
SUSE 3,212 3. 5096 Cisco 871 0. 90% 
Unknown 3,032 3. 3096 The Linux Foundation 840 0. 90% 
IBM 2,858 3. 10% Academics 831 0. 90% 
Samsung 2,415 2. 60% AMD 820 0. 90% 
Google 2,255 2. 40% Inktank Storage 709 0. 80% 
Vision Engraving Systems 2,107 2. 30% NetApp 707 0. 80% 
Consultants 1,529 1. 70% LINBIT 705 0. 80% 
Wolfson Microelectronics 1,516 1. 60% Fujitsu 694 0. 70% 
Oracle 1,248 1. 30% Parallels 684 0. 70% 
Broadcom 1,205 1. 30% ARM 664 0. 70% 
贡献 前 30 名 的 公司 中 半导体 厂商 就 有 11 家 ， 约 占 三 分 之 一 ， 如 果 算 上 硬件 相关 的 公司 





会 超过 20 家， 贡献 总 量 超过 了 60% 。 可 见 硬件 厂商 对 Linux 内 核 的 贡献 是 很 大 的 ， 对 Linux 
内 核 的 影响 也 是 巨大 的 。 从 这 份 表 中 笔者 惊喜 地 发 现 ， 笔 者 之 前 就 职 的 公司 Texas Instru- 
ments (简称 TI) 也 在 其 中 ， 并 且 贡 献 量 排名 第 四 ， 在 半导体 厂商 中 仅 在 Intel 巨头 之 后 。 在 
主要 以 ARM 为 核心 的 半导体 的 厂商 中 (如 TI, ZE, mH. RE. Xfpik. KR), 
TI 的 贡献 则 排名 第 一 。 

Linux 内 核 的 开发 需要 硬件 厂商 的 支持 和 参与 ， 源 于 两 个 方面 : 一 方面 硬件 是 Linux 内 
核 工作 的 环境 和 基础 ， 内 核 需要 使 用 相应 的 硬件 ; 另 一 方面 Linux 内 核 的 发 展 趋势 是 在 提高 
硬件 的 使 用 效率 的 同时 保证 设备 功 耗 的 最 小 化 。 这 些 都 要 求 硬 件 厂 商 更 多 地 参与 到 内 核 的 开 
发 以 及 设计 工作 中 ， 只 有 更 好 地 理解 硬件 才能 更 好 地 设计 与 实现 内 核 。 理 解 硬 件 能 使 我 们 更 
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好 地 理解 内 核 的 各 个 组 成 部 分 ， 在 驱动 方面 理解 便 件 及 其 工作 方式 则 更 为 重要 。 








1.2 从 了 解 硬 件 开 始 


内 核 是 执行 在 处 理 器 之 上 的 ， 从 Linux Foundation 发 布 的 《Who Writes Linux》 报 告 中 我 
们 已 经 看 到 ,TI 在 以 ARM 为 核心 的 能 入 式 处 理 器 厂商 中 贡献 排名 第 一 ， 本 书 以 TI ASR ASK 
处 理 器 DM 3730 为 主 介 绍 内 核 以 及 驱动 的 实现 ， 同 时 会 扩展 到 TI 的 Davinci 系列 和 Sitara A 
列 蕊 片 。 涉 及 到 的 知识 可 以 扩展 到 所 有 人 处理 器 的 内 核 以 及 驱动 的 实现 ， 只 是 一 些 实现 机 制 和 
细节 不 同 黑 了 。 


1.2.1 最 小 系统 


我 们 先 从 系统 的 角度 看 看 ， 最 基本 的 人 硬件 需求 是 什么 ? 笔者 认为 是 能 执行 ， 能 进行 运 
算 。 并 不 需要 复杂 的 输入 输出 设备 ， 只 要 能 处 理 数 据 、 能 运行 就 可 以 。 那 么 这 种 需求 的 最 小 
系统 是 什么 样子 的 呢 ? 

图 1-1 是 LogicPD 公司 基于 DM 3730 处 理 器 的 SOM (System on Module) 。 可 以 看 到 非常 
的 小 ， 比 硬币 大 不 了 多 少 ， 这 个 系统 只 要 接 上 电池 就 可 以 运行 了 。 不 要 以 为 这 么 小 ， 能 力 就 
Fo Motorola 的 里 程 碑 系列 手机 使 用 的 就 是 同样 的 处 理 器 核心 ， 是 不 是 有 些 “007” 设 备 的 


感觉 呢 ! 








图 1-1  LogicPD DM 3730 SOM 示意 图 


再 来 看 看 LogicPD 的 SOM 都 有 些 什 么 ， 系 统 框图 如 图 1-2 所 示 。 

主要 的 芯片 就 三 个 : 

(D PMIC; 它 负责 供电 。 

@) DM 3730; 它 是 主 处 理 器 。 

(3) NAND Flash/mDDR SDRAM chip : 它 是 存储 芯片 ， 一 个 芯片 中 包括 mDDR SDRAM 和 
NAND Flash。 

大 家 注意 到 框图 中 的 PoP technology f Hj? PoP 是 Package on Package 的 缩写 ， 就 是 把 两 
个 芯片 背靠背 地 焊 在 一 起 ， 这 个 非 同一 般 ， 说 明 它 们 的 关系 非常 亲密 ， 要 不 为 什么 不 把 别 的 
its Fr PoP 在 一 起 呢 。PoP 在 一 起 的 芯片 分 别 是 主 处 理 器 DM 3730 和 NAND Flash/mDDR 
SDRAM chip, EAH AA FEMA BS ie, KA ARAB, AERE PoP 的 资本 。 
PoP 的 优势 很 明显 就 是 使 电路 板 的 面积 减 小 了 ， 这 个 对 于 手机 等 对 电路 板 大 小 要 求 高 的 设备 
来 说 是 非常 重要 的 。 

另外 需要 注意 两 点 : 其 一 是 框图 的 左上 从 Connectors 引入 的 power， 其 二 是 两 个 时 钟 
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Al 1-2 LogicPD DM 3730 SOM 系统 框图 





(一 个 是 32 kHz Crystal， 另 一 个 是 26 MHz Oscillator) 。 为 什么 要 用 两 个 时 钟 ， 后 续 讲 解 电 源 
管理 实现 时 会 讲 到 。 注 意 这 两 点 主要 是 想 向 大 家 说 明 ， 数 字 系统 中 ，power 和 clock 的 概念 
一 定 要 有 ， 任 何 数字 芯片 以 及 芯片 内 部 的 数字 模块 都 需要 power 和 clock， 没 有 了 两 者 中 任 
nou m m nu ru 
和 clock, power 和 clock 也 会 贯穿 整个 电源 管理 以 及 内 核 的 驱动 中 。 这 是 本 书 强调 的 第 一 个 
概念 ， 也 是 非常 重要 的 概念 。 

剩 下 的 就 是 和 Connectors 连接 的 输入 输出 设备 ， 后 续 章 节 讲 驱动 的 时 候 都 会 涉及 。 

笔者 和 朋友 一 起 做 的 SOM 也 是 这 种 类 型 。 只 是 将 NAND Flash/mDDR SDRAM chip 换 成 了 
EMMC/mDDR SDRAM chip， 虽 然 不 能 通过 PoP 技术 来 减 小 电路 板 面积 ， 但 是 可 以 使 用 大 容量 
EMMC 来 支持 Android 4 3 (NAND 对 Android 来 说 容量 太 小 ) ， 从 这 个 角度 来 说 算是 一 件 好 事 。 


1.2.2 完整 设备 介绍 


只 是 SOM 的 话 没 有 太 多 使 用 价值 ， 真 正 的 设备 是 要 连接 很 多 复杂 外 设 的 ， 以 DM 3730 
为 基础 的 设备 框图 如 图 1-3 所 示 。 

图 1-3 引 自 TL RI (DM 3730 芯片 手册 》 中 第 136 页 框图 ， 为 了 方便 读者 在 芯片 手册 中 
查找 相关 的 内 容 ， 会 在 引用 芯片 手册 框图 时 说 明 其 所 在 的 页 码 。 笔 者 从 对 硬件 毫 无 了 解 的 计 
算 机 软件 专业 毕业 生 到 目前 个 人 感觉 对 般 入 式 真 正 了 解 的 开发 者 的 成 长 过 程 中 ，TI 的 芯片 
手册 给 了 我 很 大 的 帮助 ， 其 中 详细 讲解 了 诸多 的 原理 和 实现 细节 。 当 然 很 多 人 会 觉得 几 千 页 
的 芯片 手册 无 从 下 手 ， 但 是 对 销 研 技术 的 人 来 说 这 些 可 是 宝贝 。 如 果 大 家 可 以 静 下 心 来 仔细 
品味 ， 绝 对 会 受益 菲 浅 。 

图 中 ，DM 3730 通过 各 种 连接 方式 连接 了 各 种 设备 ， 输 入 输出 设备 根据 不 同 的 类 型 大 体 可 
以 分 为 电源 管理 、 用 户 输入 、 显 示 输 出 、 图 像 采集 、 存 储 以 及 无 线 设 备 等。 我 们 可 以 将 DM 
3730 与 这 些 设备 的 数据 接口 分 为 总 线 和 单一 的 数据 接口 总 线 。 总 线 (如 了 C、SPI 和 USB) 的 
显著 特点 是 单个 总 线 上 可 以 连接 多 个 设备 (如 User Interface 部 分 Finger Print 和 Touch Screen 
都 是 通过 SPI 总 线 和 DM 3730 进行 连接 ) ; 单一 的 数据 接口 只 连接 单一 类 型 的 设备 (如 用 于 用 
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1-3 基于 DM 3730 的 设备 框图 


户 显 示 LCD 输出 的 DSI 接口 ) 。 各 种 不 同类 型 的 数据 连接 接口 其 设计 思想 以 及 功能 是 不 同 的 ， 
PAM P C 通常 用 于 设备 的 控制 ，McBSP 用 于 音频 数据 的 传输 等 。 需 要 注意 的 是 同一 总 线 可 以 连 
接 不 同类 型 的 设备 ， 比 如 MMC 可 以 连接 SD 卡 也 可 以 连接 WIFI 设备。 这 些 接口 都 是 长 期 发 展 
的 行业 标准 ， 是 需要 软件 适应 并 满足 的 需求 。DM 3730 作为 SoC， 其 中 包含 图 中 所 有 接口 控制 
器 ， 相 应 的 控制 器 用 于 按照 相关 的 总 线 和 接口 标准 进行 数据 传输 。 驱 劲 的 开发 人 员 必须 了 解 对 
应 的 总 线 以 及 接口 知识 ， 相 关 知 识 理解 越 深 刻 ， 解 决 问题 就 越 游 刀 有 余 。 

为 什么 要 有 这 么 多 连接 方式 呢 ? 这 和 数据 传输 的 需求 、 数 据 的 特性 及 复杂 程度 相关 ， 比 
如 数字 信号 通常 依靠 clock 信号 同步 ， 那 么 相应 的 带宽 就 是 Felock x bits, bits 为 并 行 传输 的 
位 数 ， 总 线 设计 的 时 钟 频率 范围 不 同 、 位 数 不 同 相应 的 带宽 就 不 同 ， 而 频率 和 位 数 不 能 随意 
提高 ， 高 速 信号 会 产生 电磁 效应 影响 其 他 信和 号 的 完整 性 ， 另 外 从 需求 的 角度 来 讲 ， 不 是 所 有 
类 型 的 数据 都 需要 高 速 传输 ， 比 如 控制 数据 可 以 通过 下 C 传输 ， 这 种 2 线 低 时 钟 扩展 性 较 好 
的 总 线 ， 能 够 方便 的 进行 硬件 设计 并 通过 其 连接 各 种 各 样 的 传感器 ， 丰 富 我 们 的 实际 生活 。 
在 高 速 数据 总 线 设计 方面 ， 信 和 号 频率 越 来 越 高 ， 并 行 信号 在 高 主 频 时 会 有 先天 的 劣势 ， 很 难 
保证 信号 完整 性 ， 而 差分 信号 则 可 以 避免 相应 的 问题 ， 现 如 今 视频 输入 输出 、 高 速 硬 盘 、PCI 
甚至 连 外 部 memory 都 逐渐 转向 差分 信号 的 传输 方式 ， 伴 随 而 来 的 问题 就 是 对 相关 接口 的 调试 
会 复杂 一 些 ， 需 要 理解 协议 。 男 外 信号 的 分 析 需 要 专门 的 设备 ， 这 和 调试 并 行 信号 只 需要 示 波 
器 比 起 来 就 显得 复杂 得 多 了 。 总 之 对 接口 来 讲 ， 最 需要 了 解数 据 是 如 何 组 织 传输 的 。 
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1.2.3 电源 管理 相关 基础 

目前 嵌入 式 设 备 很 多 都 是 电池 供电 ， 这 类 设备 电池 续航 能 力 成 为 人 们 重点 关注 的 指标 之 
一 ， 这 就 引出 了 一 个 新 的 技术 方向 电源 管理 技术 。 

首先 了 解 一 下 散 入 式 芯 片 功 耗 和 哪些 因素 相关 : 


The active power for a CMOS device is defined as; P 2 CV^F, where P = active power needed 











for switching, C =total capacitance being switched, V = operating voltage and F = switching frequency, 
这 段 英文 说 明了 影响 功 耗 的 因素 ，C 主要 和 世 片 的 逻辑 单元 的 状态 相关 ， 通 常 逻辑 单元 
关 掉 时 C 的 值 比较 低 ; V 是 操作 电压 ; 了 是 工作 频率 。 注 意 功 耗 的 需求 是 在 稳定 工作 的 前 提 
之 下 的 ， 而 从 公式 中 明显 看 出 影响 最 大 的 因素 是 V。 围 绕 着 C、V 和 了 会 有 很 多 电源 管理 技 
术 的 实现 ， 后 续 会 有 详细 的 解析 。 
接 下 来 以 DM 3730 为 例 了 解 一 下 主 芯片 和 电源 管理 芯片 的 连接 ， 如 图 1-4 所 示 。 
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Al 1-4 是 引 自 《DM 3730 芯片 手册 》 中 第 239 页 的 框图 ， 其 中 PRCM Æ power reset 
clock management 的 缩写 ， 它 是 对 电源 、 启 动 信号 和 时 钟 进行 管理 的 模块 。 从 图 中 我 们 看 到 
时 钟 信号 (如 sys_32k) 和 多 个 电源 (如 vdd 开头 的 连接 ) 都 是 由 电源 芯片 (Power IC) 提 
供 的 ， 为 什么 要 提供 多 个 电源 呢 ? 这 是 因为 SoC 中 不 同 的 工作 单元 需要 的 电压 不 同 ， 如 果 都 
要 求 高 电压 ， 根 据 之 前 的 公式 ， 功 耗 影响 会 比较 大 ， 通 过 隔离 不 同 的 工作 电压 可 以 降低 整体 
的 功 耗 。 电 源 管理 技术 的 大 部 分 操作 就 是 围绕 着 这 几 路 电源 和 时 钟 展开 的 。 

这 里 我 们 看 到 一 路 电源 的 名 字 是 vdda_sram， 这 说 明 芯 片 内 部 有 sram， 这 部 分 memory 在 
系统 启动 和 电源 管理 的 一 些 特殊 操作 时 起 到 至 关 重 要 的 作用 ， 另 外 这 部 分 memory 访问 效率 
非常 高 ， 可 以 用 来 提高 系统 性 能 。 

在 图 中 还 有 诸多 疑问 ， 比 如 PRCM 详细 内 容 ， 具 体 功 能 是 什么 ? Wi PC 接口 的 作用 是 
什么 ? 多 路 电源 (如 vdd_mpu_iva 等 ) 具体 功能 是 什么 ”其 他 部 分 的 信号 起 什么 作用 ? 这 里 
先 了 解 基本 概念 ， 这 些 疑 问 会 在 后 续 电 源 管理 的 详解 中 进行 说 明 。 


1.3 从 设备 看 内 核 应 该 满足 的 需求 


对 硬件 有 了 基本 的 了 解 ， 就 可 以 从 硬件 出 发 考虑 内 核 应 该 满足 的 需求 了 。 

硬件 的 类 型 是 多 种 多 样 的 ， 连 接 的 接口 也 是 变化 多 样 的 ， 作 为 内 核 的 一 个 最 基本 的 要 求 
就 是 能 够 访问 并 操作 这 些 设备 ， 这 就 需要 大 量 的 设备 驱动 支持 。 同 时 也 要 支持 各 种 不 同 的 数 
据 连 接 接 口 。 内 核 也 需要 支持 各 种 总 线 ， 并 且 要 支持 各 种 类 型 的 设备 ， 由 于 总 线 要 符合 一 定 
的 协议 并 连接 多 个 设备 ， 所 以 通常 分 为 总 线 控制 的 主 设备 以 及 连接 进行 总 线 响 应 的 从 设备 ; 
内 核 会 应 用 到 各 种 设备 ， 所 以 需要 同时 为 各 种 总 线 的 主 设备 以 及 从 设备 提供 支持 。 当 然 电源 
管理 的 需求 会 涉及 以 上 各 种 设备 、 总 线 和 接口 。 另 外 内 核 不 能 只 是 支持 特定 的 处 理 器 ， 需 要 
支持 各 种 类 型 的 处 理 器 ， 学 术 一 点 的 说 法 就 是 要 支持 各 种 体系 结构 。 

还 有 一 点 比较 重要 的 思路 就 是 ， 大 型 的 系统 会 涉及 很 多 人 共同 开发 ， 这 就 对 代码 的 可 维 
护 性 和 重用 性 提出 了 很 高 的 要 求 ， 针 对 这 个 需要 在 设计 过 程 中 内 核 会 将 各 种 共同 的 资源 抽象 
出 来 统一 管理 ， 并 考虑 硬件 无 关 性 形成 相应 的 模块 或 者 函数 接口 以 供 开发 者 使 用 。 

总 结 下 来 从 设备 出 发 看 内 核 要 满足 以 下 需求 : 

能 支持 不 同 的 体系 结构 和 处 理 器 。 
能 支持 不 同 的 总 线 连接 以 及 总 线 设备 。 
能 支持 不 同 的 数据 连接 接口 以 及 相应 的 设备 。 

© 能 文 持 各 个 级 别 的 电源 管理 功能 。 

e 设计 时 要 考虑 硬件 无 关 性 提高 各 模块 的 重用 性 。 

前 四 项 都 是 比较 直接 的 需求 ， 第 五 项 则 是 考验 开发 人 员 的 设计 能 力 ， 也 是 内 核 的 各 个 模 
块 的 设计 重点 以 及 我 们 研究 的 重点 。 










































































1.4 所 涉及 的 重要 概念 


谈 到 Linux 内 核 ， 大 家 的 第 一 感觉 就 是 一 个 庞大 的 系统 、 很 多 的 模块 和 功能 ， 实 在 是 太 
复杂 了 。 究 竟 如 何人 手 是 个 问题 。 对 系统 的 理解 有 很 多 的 方法 : 目 顶 向 下 、 自 底 向 上 等 。 笔 
6 














者 更 认同 自 顶 向 下 按 层次 分 析 的 方法 。 顶 部 是 用 户 的 直接 接口 和 需求 体现 ， 按 照 需求 从 整体 
到 局 部 会 更 容易 理解 系统 ， 也 更 容易 设计 与 实现 系统 。 整 本 书 的 论述 也 是 从 需求 出 发 试图 按 
照 What (需求 是 什么 ) >How ( 如 何 实 现 ) 的 逻辑 解释 系统 、 子 系统 及 各 个 模块 。 

本 书 中 还 会 涉及 一 些 重要 的 概念 ， 如 资源 、 数 据 、 数 据 流 、 接 口 、 临 界 区 、 锁 、 执 行 实 
体 、 上 上 下文、 同步 、 异 步 、 时 间 、 空 间 和 抽象 等 。 需 要 读者 对 这 些 概念 有 基本 的 认识 。 下 面 
重点 介绍 这 些 概 念 与 需求 之 间 是 怎样 的 关系 。 

首先 需求 分 为 功能 需求 和 性 能 需求 ， 这 两 种 需求 都 会 影响 系统 的 实现 。 

在 实现 需求 的 时 候 要 考虑 资源 ， 有 哪些 资源 可 以 使 用 ， 如 何 使 用 来 满足 需求 ， 这 些 都 是 
要 考虑 的 。 需 要 注意 的 一 点 是 资源 通常 都 是 共享 的 ， 对 某 个 共享 资源 的 管理 使 用 通常 就 会 抽 
象 成 系统 的 一 个 模块 。 对 硬件 来 说 ， 处 理 器 、memory clock, power supplier, DMA, F WSE 
都 是 资源 。 

在 系统 中 各 种 资源 围绕 什么 进行 操作 呢 ? 是 数据 。 数 据 可 以 加 上 不 同 的 限制 条 件 ， 换 名 
话说 数据 可 以 组 织 成 不 同 的 形式 。 数 据 经 由 不 同 的 模块 处 理 可 以 理解 为 数据 在 不 同 的 模块 之 
间 流 动 ， 笔 者 称 之 为 数据 流 。 数 据 流 经 过 相 邻 两 个 模块 时 ， 双 方 要 知道 数据 是 如 何 组 织 的 ， 
从 而 才能 形成 接口 。 系 统 的 设计 与 实现 中 一 定 要 有 数据 流 的 概念 还 要 明确 接口 的 数据 组 织 形 
式 。 这 样 才 更 容易 理解 系统 是 如 何 运 作 的 ， 以 设计 出 更 好 的 系统 。 另 外 当 不 同 的 实体 共享 数 
据 时 ， 需 要 对 共享 数据 进行 保护 ， 避 免 不 同 实体 同时 访问 共享 数据 ， 这 个 保护 区 域 就 是 临界 
区 ， 保 护 方法 是 加 锁 。 

对 处 理 器 这 一 资源 的 使 用 要 有 执行 实体 的 概念 ， 执 行 实体 的 运行 受 处 理 器 的 执行 级 别 和 
运行 状态 的 影响 ， 软 件 通常 是 通过 不 同 的 栈 来 区 分 级 别 (如 进程 栈 和 中 断 栈 ) Linus 内 核 
中 断 实现 是 借用 当前 进程 的 内 核 栈 来 执行 。 不 同 的 执行 实体 与 处 理 器 的 执行 级 别 和 状态 一 起 
形成 上 下 文 的 概念 。 不 同 的 上 下 文 在 临界 区 时 需要 不 同 级 别 的 锁 。 

其 次 对 需求 的 实现 方法 通常 有 同步 、 异 步 两 种 方式 ， 需 要 注意 的 是 同步 、 异 步 概 念 在 软 
件 和 硬件 上 是 不 同 的 。 软 件 中 同步 是 指 发 送 方 发 出 数据 后 ， 等 接收 方 发 回响 应 以 后 才 发 下 一 
个 数据 包 的 通信 方式 ; 异步 是 指 发 送 方 发 出 数据 后 ， 不 等 接收 方 发 回响 应 ， 接 着 发 送 下 个 数 
据 包 的 通信 和 方式。 硬件 中 同步 信号 和 时 钟 信号 有 关 ， 实 际 上 输入 信号 和 时 钟 信号 进行 了 与 运 
算 或 与 非 运 算 ， 输入 信号 和 时 钟 信号 的 运算 结果 为 有 效 状态 时 ， 融 件 的 状态 才 会 改变 ; 异 ; 
输入 信号 和 时 钟 信号 无 关 ， 输 入 信号 变 为 有 效 状 态 时 ， 器 件 的 状态 就 会 立即 改变 。 可 见 软 件 
和 硬件 对 同步 、 异 步 的 理解 所 站 的 立场 不 同 ， 软 件 站 在 发 送 者 的 立场 ， 人 硬件 则 是 站 在 接收 者 
如 何 确 认 数 据 有 效 的 立场 ， 这 与 软件 和 硬件 的 不 同 特点 是 分 不 开 的 。 这 些 概念 我 们 要 有 ， 并 
且 需 要 在 驱动 的 设计 与 实现 中 随时 站 在 不 同 的 立场 上 考虑 问题 。 需 要 注意 : 软件 、 硬 件 的 同 
步 、 异 步 的 概念 虽然 有 区 别 ， 但 是 也 有 关联 。 比 如 软件 中 ， 蜡 步 概念 的 实现 很 多 时 候 是 通过 
硬件 的 异步 事件 CAPT) 来 实现 的 。 

在 实现 需求 时 还 要 考虑 时 间 、 空 间 的 概念 。 这 里 时 间 主 要 是 性 能 需求 ， 空 间 主 要 是 对 存 
储 资 源 的 占用 。 计 算 机 专业 的 学 生 经 常会 听 到 老师 讲 “ 时 间 换 空间 ， 空 间 换 时 间 ”， 这 人 句 话 
体现 了 效率 和 资源 之 间 置 换 的 思想 ， 如 果 想 提高 效率 通常 就 要 多 占用 资源 ， 相 应 的 如 果 资 源 
是 瓶颈 就 要 牺牲 效率 。 所 以 在 系统 设计 实现 中 一 定 要 首先 搞 清 楚 效率 和 资源 的 关系 ， 如 果 本 
ABE, ASEM, Linux 内 核 在 设计 过 程 中 这 些 都 已 考虑 在 其 中 ， 这 也 就 提升 了 它 的 
适用 范围 。 









































最 后 ， 软 件 实现 需要 进行 抽象 。 抽 象 是 人 类 的 一 个 重要 思维 能 力 ， 从 某 种 角度 来 说 软件 
系统 是 对 各 种 概念 或 者 行为 进行 抽象 ， 并 加 以 管理 。 抽 象 在 系统 设计 中 主要 体现 在 将 共性 提 
取 形 成 概念 ， 抽 象 的 概念 通常 包括 属性 及 其 相应 的 行为 ， 这 在 内 核 的 设计 中 处 处 可 见 ， 比 如 
file 结构 为 各 种 文件 的 抽象 。 各 种 硬件 资源 在 内 核 中 也 会 有 相应 的 抽象 实体 存在 。 我 们 在 学 
习 内 核 的 过 程 中 经 常 考虑 这 些 抽 象 概念 包括 哪些 属性 以 及 如 何 操 作 ， 就 像 走 了 一 遍 内 核 的 设 
计 过程 。 比 起 一 味 的 死记 人 硬 背 会 更 好 地 帮助 我 们 理解 系统 。 

















1.5 小 结 


本 章 从 观察 硬件 设备 出 发 来 探讨 内 核 应 该 满足 哪些 需求 ， 让 大 家 对 硬件 以 及 电源 管理 有 
一 个 基本 的 认识 ， 大 致 理解 内 核 应 该 满足 的 需求 。 最 后 介绍 了 本 书 涉及 的 重要 概念 与 需求 的 
关系 ， 以 帮助 大 家 对 后 续 内 容 进行 学 习 。 





第 2 章 TI 应 用 处 理 如 心 片 及 其 内 核 特 点 


在 后 PC 时 代 ， 骨 入 式 系统 得 到 了 空前 的 发 展 ， 租 入 式 产品 已 经 随处 可 见 。 随 着 网 络 技 
术 和 移动 通信 的 发 展 ， 手 机 作为 高 端 负 入 式 系 统 更 是 成 为 人 们 日 常生 活 中 必 不 可 少 的 工具 。 
币 人 式 处 理 需 是 岩 入 式 系 统 的 核心 ， 单 一 的 能 入 式 处 理 吉 是 无 法 满足 小 到 电子 玩具 大 到 飞机 
控制 系统 的 所 有 需求 的 。 面 对 各 种 各 样 的 需求 ， 散 入 式 产品 三 商 的 首要 工作 就 是 选择 合适 的 
忆 片 实现 自己 的 系统 ， 换 名 话说 就 是 嵌入 式 产 品 的 设计 与 实现 要 从 “ 蔚 ” 开 始 。 了 解 圣 入 
式 系统 也 要 从 “ 必 ” 开 始 。 

随 着 时 间 的 推移 和 技术 的 进步 ， 在 工业 控制 和 新 兴 的 手持 式 应 用 等 领域 ， 用 户 体验 成 为 
产品 成 功 的 关键 因素 之 一 ， 越 来 越 多 的 产品 需要 良好 的 用 户 界面 、 互 联 功能 以 及 较 强 的 数据 
处理 能 力 。T 了 I 公司 作为 老牌 的 岁入 式 处 理 絮 提供 商 ， 为 了 应 对 艇 入 式 中 、 高 端 应 用 领域 ， 
如 工业 控制 、POS 机 、 网 络 设备 、 图 像 处 理 、 手 机 等 不 同 的 需求 ， 于 2008 年 之 后 分 别 推出 
T DM 3730 系列 、DM 81XX 系列 和 Sitara 系列 芯片 。 这 些 蕊 片 各 有 特色 ， 它 们 可 以 涵盖 舱 
入 式 中 、 高 端 应 用 的 各 个 领域 。 























2.1 DM 3730 微 处 理 器 


提 到 DM 3730 芯片 就 不 得 不 提 到 OMAP3 系列 芯片 ， 光 说 OMAP3 知道 的 人 会 比较 少 ， 
但 是 提 到 Motorola 的 Milestone 手机 知道 的 人 就 多 了 。Milestone 手机 正如 其 名 开创 了 Android 
?能 手机 的 里 程 碑 。OMAP3 系列 芯片 在 手持 设备 的 应 用 见 表 2-1。 


表 2-1 OMAP3 系列 芯片 在 手持 设备 的 应 用 
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名 PK | 制造 工艺 | 处 理 器 指令 集 处 理 需 类 型 和 主 频 应 用 终端 
600 MHz ARM Cortex Motorola Droid/Milestone, Nokia N 900, Palm 
OMAP 3430 65 nm ARMv7 . : : 
— A8 Pre, Samsung i 8910, Sony Ericsson Satio 





Archos 5 ( Gen 7) , Motorola Milestone XT 720, 
800 MHz ARM Cortex m 
OMAP 3440 65 nm ARMv7 A8 Motorola Titanium XT 800, Samsung Galaxy A 
(SHW -M 100S), Samsung i 7680 





3630 - 1000; Archos 43, Archos 70, Archos 101, 
LG Optimus Black, LG Optimus Bright, LG Optimus 
Mach, Motorola Cliq 2, Motorola Droid 2 R2D2 Spe- 

cial Edition, Motorola Droid X, Motorola Defy +, 
600 MHz ~ 1.2 GHz 
OMAP 3630 45 nm ARMv7 Nokia N 9, Nokia N 950, Palm Pre 2, Panasonic 
ARM Cortex — A8 
P-07C, Panasonic Sweety 003P, Samsung Galaxy 
SL 19003, Sony Ericsson Vivaz, Lenovo A1-07 , Sa- 
msung Galaxy Player 4.2 ( YP - GI), Le Pan 
TC 970 














从 该 表 中 可 以 见证 OMAP3 系列 芯片 的 成 功 ， 各 大 手机 厂商 都 应 用 该 系列 芯片 推出 了 手机 
产品 ， 这 也 说 明 OMAP3 系列 世 片 非常 适用 于 手持 设备 ， 是 手持 设备 芯片 的 典范 。 





DM 3730 实际 上 使 用 的 是 OMAP 3630 AY DIE， 封 装 上 进行 修改 可 以 让 生产 厂商 使 用 
0. 8 mm 的 技术 进行 焊接 ， 这 样 的 改进 使 得 更 多 的 厂商 可 以 开发 和 生产 高 性 能 、 低 功 耗 的 手 
持 设 备 。 


2.1.1 DM 3730 微 处 理 器 框架 
DM 3730 微 处 理 如 框架 如 图 2-1 所 示 。 
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图 2-1 DM 3730 系统 框图 





Kj 2-15| EB TERS (DM 3730 芯片 手册 》 中 第 187 页 框图 。 从 框图 中 可 见 DM 3730 WE 
要 核心 与 外 围 接 口 。 

DM 3730 有 三 个 核心 处 理 器 单元 : 

(D ARM Cortex - A8 : 负责 系统 控制 和 外 围 接口 驱动 。Linux 运行 在 该 处 理 器 上 。 

QIVA2 : 负责 音 视频 编码 解码 或 者 信号 处 理 的 加 速 单元 。 其 中 包含 C64x + 核心 DSP 
以 及 视频 加 速 RMT, 具有 720P@ 30fps 的 编码 或 解码 能 力 。 

(3) PowerVR SGX: 负责 3D 演 染 的 硬件 加 速 单元 。 

主要 外 围 设备 的 接口 如 下 : 

(D Dual - output 3-layer Display Processor; 负责 处 理 UI 的 显示 可 以 实现 三 层 画 中 画 的 硬 
件 生 加， 并 支持 同时 两 个 设备 进行 显示 。 

(2) Image Capture: 负责 图 像 采 集 可 以 进行 图 像 信号 处 理 。 

®© HS - USB: 负责 USB 的 连接 ， 可 以 通过 USB 5j PC 连接 或 者 与 USB 设备 连接 。 注 意 

其 中 有 3-port Host， 最 多 可 以 连接 三 个 USB 设备 ， 很 多 手机 厂商 都 是 通过 两 个 USB Host 接 
口 实现 双 网 双人 等 手机 的 。 
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@ SDRC; 负责 DDR memory 内 存 的 连接 。 

© GPMC: 负责 各 种 Flash 存储 器 的 连接 ， 该 接口 可 以 通过 时 序 编程 与 FPCA 进行 连接 
以 扩展 功能 。 

© Peripherals; 各 种 外 设 接口 ， 如 UART ($H), PC (通常 负责 传感器 的 控制 )、 
McBSP (负责 音频 数据 传输 )、HSMMC/SDIO (负责 SD F, eMMC 或 者 WIFI 必 片 的 连接 ) , 
uSIM (负责 SIM 卡 的 连接 ) 等 。 

CO GP Timer; 可 编程 的 定时 器 ， 向 系统 提供 定时 功能 。 

除去 以 上 的 模块 之 外 还 有 模块 ; 

(D System DMA: 负责 数据 在 外 设 和 内 存 或 者 内 存 不 同 区 块 之 间 的 复制 ， 用 来 降低 处 理 
器 的 负载 以 提高 系统 性 能 。 

(2) On - Chip RAM : HAY RAM， 使 系统 在 外 部 内 存 没 有 初始 化 好 的 情况 下 仍 可 运行 。 
通常 该 段 内 存 可 用 于 系统 初始 化 ， 系 统 加 速 以 及 电源 管理 相关 的 功能 。 

(3) On - Chip ROM : 类 似 于 PC 上 的 BIOS， 其 中 包含 系统 的 初始 化 程序 。 

(4) 13 Interconnect Network : 片 内 高 速 总 线 ， 负 责 在 片 内 各 个 模块 间 建 立 高 速 数 据 通道 。 

©) IA Interconnect; 片 内 低速 总 线 ， 负 责 隔离 高 速 设 备 与 低速 设备 。 

从 DM 3730 的 框架 来 看 ， 它 非常 适合 手持 设备 的 应 用 ， 手 持 设备 通常 不 会 连接 硬盘 这 
种 高 功 耗 的 大 容量 存储 设备 而 是 用 SD 卡 进 行 替代 ，DM 3730 中 就 设计 了 三 个 HSMMC 接口 
而 去 掉 SATA 接口 以 适应 这 种 需求 。 在 总 线 方面 PCIE 由 于 功 耗 高 、 插 槽 大 不 适用 于 手持 设 
备 的 应 用 ，USB 则 是 优选 ， 相 应 的 DM 3730 中 设计 了 一 个 USB OTG 接口 和 三 个 USB Host 接 
口 满足 这 种 需求 。 另 外 为 了 降低 功 耗 ，DM 3730 的 外 部 内 存 接口 设计 成 LPDDR #20, 1/0 
工作 电压 也 设计 成 1.8V， 可 见 为 了 满足 高 性 能 低 功 耗 的 需求 ，DM 3730 在 框架 设计 方面 已 
经 做 足 了 工作 ， 这 也 是 它 能 流行 的 一 个 原因 。 


2.1.2 DM 3730 微 处 理 器 特性 


DM 3730 支持 高 性 能 手持 设备 的 典型 应 用 ， 其 特性 如 下 : 

© DM 3730 核心 处 理 器 经 过 配置 可 在 支持 低 功 耗 或 高 性 能 模式 的 多 个 工作 点 下 工作 。 

e 高 达 800 MHz 的 TMS320C64x + DSP 支持 720P@ 30fps 的 高 清 视频 编码 和 解码 ; DSP 
引擎 可 编程 ， 支 持 多 个 一 般 性 信号 处 理 任 务 ， 如 数字 滤波 、 数 学 函数 以 及 影像 处 理 与 
分 析 等 。 

e 具备 PowerVR 200 MHz 图 形 加 速 器 ， 支 持 OpenGL ES 2. 0， 每 秒 可 泻 染 2 千 万 个 多 边 
形 ， 并 具有 高 级 显示 子 系统 。 

e1.8V 的 IO 接口 降低 L/O 功 耗 适 合 电池 供电 的 系统 。 

e 芯片 待机 功 耗 低 于 0. 1 mW, 

为 了 支持 手持 设备 各 种 情况 下 功 耗 的 需求 ，DM 3730 电源 管理 方面 的 特性 如 下 : 

e 内 部 时 钟 管理 。 

e 内 部 启动 信号 管理 。 

e 唤醒 事件 管理 。 

e 智能 反馈 电源 管理 。 

e 动态 电压 /频率 管理 。 
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e 待机 功 耗 管理 。 
2.1.3 DM 3730 微 处 理 器 电源 管理 相关 设计 


1. DM 3730 使 用 的 电源 管理 技术 介绍 

电源 管理 的 相关 技术 都 是 以 第 1 章 讨论 过 的 公式 P=CV?F 为 原理 出 发 的 。DM 3730 中 
使 用 了 两 个 比较 重要 的 电源 管理 技术 DVFS (动态 电压 /频率 调整 ) 和 AVS (电压 适 配 调 
整 ) 。 先 看 看 DVFS ， 从 公式 出 发 可 以 知道 降低 频率 就 可 以 降低 功 耗 ， 然 而 直接 降低 频率 对 
相同 工作 量 的 任务 就 需要 更 多 的 时 间 完 成 ， 如 此 看 来 并 没有 起 到 降低 功 耗 的 作用 ， 执 行 时 间 
变 长 了 ， 用 户 体验 也 不 好 。 从 公式 出 发 看 看 降低 电压 的 效果 ， 由 于 降低 电压 对 芯片 工作 稳定 
性 会 有 影响 ， 所 以 一 般 在 降低 电压 的 同时 是 要 降低 频率 的 ， 这 样 一 来 完成 相同 的 任务 也 会 消 
耗 更 多 的 时 间 ， 所 以 降低 电压 会 是 一 个 连锁 反应 ， 但 是 从 公式 可 以 看 到 电压 对 功 耗 的 影响 是 
， 可 见 电压 影响 更 大 。 举 个 例子 电压 为 1V 时 执行 1s 的 任务 如 果 消 耗 1J 的 能 量 ， 那 么 主 
频 降 为 原来 的 一 半 时 所 需要 的 电压 大 概 是 0.7V， 这 样 同 样 的 任务 大 概 需要 2s， 这 样 算 下 来 
消耗 的 功 耗 大 概 是 0.5J， 总 体 算 下 来 降低 电压 和 频率 能 使 功 耗 大 大 降低 ， 但 是 这 种 功 耗 的 
降低 的 代价 就 是 要 用 时 间 来 换 ，DVFS 就 是 在 不 同 的 OPP (operating point， 操 作 点 ) 之 间 调 
节 ， 每 个 OPP 对 应 一 组 电压 和 频率 。 既 然 DVFS 是 通过 时 间 来 换取 功 耗 的 降低 ， 那 么 有 没有 
无 代价 的 降低 功 耗 的 技术 呢 ? 答案 是 有 的 ， 这 就 是 AVS，AVS 从 字面 adaptive voltage scaling 
理解 是 电压 适 配 调整 ， 究 竟 怎 么 电压 适 配 呢 ? 图 2-2 说 明了 AVS 的 基本 原理 ， 适 配 这 个 词 
突出 了 芯片 的 个 性 和 环境 的 差异 ， 适 配 实 际 上 就 是 适 配 芯片 个 体 情况 ， 对 不 同 芯 片 的 工作 电 
压 一 定 要 保证 适应 最 差 的 情况 ， 如 图 2-2 中 OPP1 OPP2 和 OPP3 连 成 的 线 ， 只 有 使 用 最 差 
情况 的 设置 才能 满足 所 有 芯片 的 需求 。 情 况 好 的 芯片 ， 如 果 也 要 在 最 差 情 况 的 电压 下 工作 ， 
这 就 会 产生 功 耗 的 浪费 ， 所 以 需要 适 配 来 降低 功能 。 
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图 2-2 电压 适 配 调整 原理 

















针对 AVS 的 需要 ，TI 设计 了 SmartReflex 智能 反馈 电压 控制 技术 ， 实 现 框架 如 图 2-3 所 
示 。 该 图 引 自 TI 的 《DM 3730 芯片 手册 》 中 第 234 页 框图 。 
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从 图 2-3 Pay UL, A Voltage processor ( HAE PE TAR) 对 当前 芯片 的 个 性 数据 进行 计算 ， 
然后 通过 特定 的 了 C 接口 和 电源 管理 芯片 通信 ， 控 制 电源 管理 芯片 的 电压 输出 ， 进 而 为 芯片 
提供 合适 的 电压 。SmartReflex 会 通过 对 输入 电压 进行 检测 以 及 提取 芯片 自身 工作 状态 的 数据 
为 电压 控制 器 提供 操作 的 依据 ， 这 样 就 形成 一 套 完整 的 反馈 系统 ， 合 理 根据 芯片 自身 的 工作 
情况 调整 工作 电压 使 功 耗 最 低 ， 从 而 降低 芯片 的 功 耗 。 

电源 管理 技术 中 ，DVFS 是 对 电压 的 大 范围 的 调整 ， 而 AVS 是 针对 某 个 OPP 情况 下 电 
压 小 范围 的 调整 ， 两 者 完美 的 结合 就 能 实现 功 耗 最 大 的 优化 。 

2. DM 3730 电源 管理 模块 详解 

(1) 与 电源 管理 芯片 相关 的 设计 

DM 3730 中 实现 电源 管理 技术 的 模块 是 PRCM ，PRCM 是 power reset clock management 的 
缩写 ， 从 名 字 就 可 以 看 出 该 模块 管理 芯片 内 部 的 电源 、 启 动 和 时 钟 信 叶 。PRCM 的 系统 框图 
如 图 2-4 所 示 。 

图 2-4 引 自 开 的 《DM 3730 芯片 手册 》 中 第 237 页 框图 ， 在 该 框图 中 我 们 明显 看 到 有 
5 个 VDD， 每 个 VDD 对 应 一 个 voltage domain (电压 域 ) ， 它 提供 一 种 电压 规格 ， 可 以 为 多 
个 有 相同 电压 需求 的 模块 提供 电源 ，voltage domain 也 可 以 理解 为 完整 的 物理 供电 线路 。 设 
计 多 个 VDD 的 好 处 是 可 以 隔离 不 同 的 电源 需求 ， 在 DM 3730 特性 中 已 经 介绍 ， 它 的 待机 功 
uL DU a 就 必须 将 待机 时 工作 的 模块 最 小 化 ， 并 且 其 他 模块 

不 能 有 漏电 流 ， 由 于 只 要 有 电压 差 就 会 有 漏电 流 ， 这 就 需要 主要 的 模块 在 待机 时 电源 完全 关 
掉 使 电压 降 为 0V。 为 了 达到 如 此 低 的 功 耗 ， 图 2-4 中 的 VDD1 和 VDD2 在 待机 时 都 要 降 为 
OV, 根据 第 1 章 的 图 1-4， 可 知 VDDI ~ VDD5 都 是 来 源 于 电源 管理 芯片 ， 所 以 如 果 要 改变 
任意 一 个 VDD 的 电压 都 是 需要 和 电源 管理 芯片 配合 ， 由 电源 管理 芯片 完成 实际 的 操作 ， 可 
以 说 电源 管理 芯片 就 是 按照 DM 3730 的 要 求 进行 操作 ， 同 样 的 VDD1 和 VDD2 降 为 0V 也 是 
DM 3730 请 求 电 源 管 理 芯 片 完 成 的 ， 这 个 请 求 在 DM 3730 设计 中 采用 了 最 简单 的 办 法 即 通 
过 一 个 引 脚 (图 2-4 中 的 sys off mode) 极 性 的 改变 就 完成 了 。 在 第 1 章 有 个 遗留 问题 是 关 
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| 2-3  SmartReflex 实现 框架 
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2-4 PRCM 系统 框图 





于 最 小 系统 框图 中 为 什么 有 两 个 时 钟 (一 个 是 32 kHz Crystal ， 另 一 个 是 26 MHz Oscillator) 。 
现在 可 以 说 明 一 下 ,图 2-4 中 实际 也 有 两 个 时 钟 信 号 ， 分 别 是 sys_32k (BEA 32k 时 钟 信 
号 ) 和 sys_xtalin (££ A 26M 时 钟 信号 ) ， 在 提供 系统 内 部 时 钟 的 时 候 ， 是 需要 锁 相 环 进行 
倍 频 的 ， 由 于 内 部 最 高 达到 1 GHz 的 频率 ， 所 以 需要 26 MHz 时 钟 来 倍 频 ， 可 以 说 26 MHz 时 
钟 是 内 部 所 有 时 钟 的 “父亲 ”。 这 样 就 遇 到 一 个 问题 ， 在 待机 的 时 候 如 果 还 是 使 用 26 MHz 
这 种 高 速 的 时 钟 ， 那 么 功 耗 就 会 有 比较 多 的 浪费 ，DM 3730 设计 的 时 候 考 虑 到 该 问题 ， 当 待 
机 时 只 要 提供 32 kHz 的 时 钟 就 能 保证 必要 的 模块 待机 ， 从 而 尽量 减少 功 耗 。 由 于 时 钟 也 是 
电源 管理 芯片 输出 的 ， 如 果 要 停 掉 高 频 时 钟 也 需要 一 个 信号 ， 这 个 信号 就 是 图 2-4 中 的 sys_ 
clkreq 信和 号。 可 以 看 到 DM 3730 的 很 多 电源 管理 功能 还 是 需要 电源 管理 芯片 的 特殊 支持 ， 所 
14 














以 要 达到 好 的 电源 管理 效果 需要 能 文 持 这 些 特殊 功能 的 电源 管理 芯片 。TI 为 DM 3730 设计 
了 一 系列 电源 管理 芯片 如 TPS 65950 等 ， 这 样 使 用 DM 3730 再 加 上 TPS 65950 的 配合 就 能 
达到 很 好 的 待机 功 耗 ，TI 的 参考 设计 中 也 是 这 么 实现 的 。 

(2) 芯片 内 部 电源 控制 设计 

图 2-4 中 的 左 侧 可 以 看 到 两 个 名 词 : voltage domain 和 power domain, voltage domain 中 包 
fF power domain, voltage domain 已 经 做 过 介绍 就 是 电压 域 ，power domain 从 名 字 可 知 是 和 
power 相关 的 概念 ， 它 是 电源 控制 的 基本 单元 ， 控 制 整个 域 电源 的 开关 。 在 优秀 的 电源 管理 
设计 中 ， 不 使 用 的 模块 应 该 是 可 以 完全 切断 电源 的 ， 这 样 可 以 达到 降低 功 耗 的 目的 。power 
domain 正 是 基于 这 个 概念 设计 的 。 由 于 设计 的 复杂 度 也 是 要 考虑 的 因素 ,权衡 下 来 ， 把 那 
些 能 够 一 起 开关 的 模块 放 在 一 起 ， 形 成 一 个 power domain。 可 见 ，power domain 实际 上 是 个 
逻辑 的 概念 ， 逻 辑 上 一 起 开关 的 模块 都 可 以 做 到 power domain 中 ， 这 样 有 一 个 问题 就 是 volt- 
age domain 是 和 物理 电压 相关 的 概念 ， 而 power domain 则 是 逻辑 的 概念 ， 那 么 这 两 个 概念 之 
间 的 关系 就 不 是 纯粹 的 包含 与 被 包含 ， 而 是 相互 重 登 的 概念 ， 比 如 一 个 power domain 可 以 在 
不 同 的 voltage domain 中 ， 这 些 都 取决 于 设计 需求 。 有 了 power domain 之 后 ， 系 统 在 不 需要 
某 些 功能 的 时 候 就 可 以 将 相应 的 power domain 完全 关 断 以 节省 电能 ， 可 以 说 是 按 需 取 能 ， 该 
功能 不 仅 在 电池 供电 的 设备 中 需要 ， 在 提倡 节能 环保 的 今天 可 以 说 所 有 的 电子 设备 都 需要 ， 
为 了 能 使 设备 的 某 些 功能 按照 需要 进行 开关 ，Linux 设计 了 runtime power management 框架 。 

回 过 头 来 继续 讨论 voltage domain 和 power domain 在 DM 3730 中 的 实现 , 图 2-5 引 自 TI 
AY (DM 3730 芯片 手册 》 中 第 371 页 框图 ， 其 中 描述 了 DM 3730 中 voltage domain 和 power 
domain 的 具体 关系 。 

图 2-5 中 需要 注意 两 个 部 分 : 

其 一 ， 就 是 VDD3 voltage domain 和 其 中 的 WKUP domain, AAI 2-4 中 可 以 看 出 VDD3 
是 由 vdd3_wkup_bg_bb 单独 提供 的 一 路 电源 ， 在 图 2-5 中 可 以 看 出 只 有 VDD3 voltage domain 
中 包含 唯一 的 power domain HJ WKUP domain, ， 也 就 是 说 WKUP domain 单独 由 一 路 电源 供电 ， 
可 见 WKUP domain 的 重要 性 。WKUP domain 之 所 以 重要 是 因为 在 整个 DM 3730 的 各 个 pow- 
er domain 中 需要 一 个 一 直 保持 上 电 的 模块 ， 这 个 模块 需要 功能 最 小 ， 在 需要 低 功 耗 的 时 候 
其 他 power domain 都 关闭 ， 留 下 该 domain 当 守 卫 ， 监 视 外 部 环境 。 如 果 有 外 部 信号 需要 系 
统 启动 工作 ， 该 模块 还 需要 唤醒 系统 ，WKUP 是 wake up 的 缩写 ， 表示 该 模块 上 电 之 后 一 直 
保持 清醒 ， 可 见 这 是 一 个 很 辛 昔 很 重要 的 模块 。WKUP domain 中 包括 一 组 GPIO 、 一 个 通用 
定时 器 和 一 个 看 门 狗 定时 器 ， 这 些 都 是 在 系统 进入 待机 状态 后 能 响 醒 系统 所 需要 的 基本 硬 
件 ， 从 中 可 以 看 出 要 设计 有 良好 的 电源 管理 功能 的 芯片 需要 考虑 很 多 细节 。 

其 二 ， 就 是 框图 中 有 些 部 分 在 两 个 voltage domain 内 ， 例 如 很 多 模块 的 SRAM 分 为 Logic 
和 Array 两 部 分 ， 并 且 分 别 在 两 个 不 同 的 voltage domain PY, SRAM 是 每 个 模块 内 部 的 memory, 
比如 cache, line buffer 等 。 这 部 分 的 逻辑 和 存储 分 开 是 有 好 处 的 ， 可 以 保证 存储 的 内 容 和 访 
问 操作 完全 分 离 ， 保 证 逻辑 和 存储 可 以 单独 设置 电源 管理 等 级 ， 可 以 保证 在 信息 不 丢失 的 情 
况 下 尽量 减少 功 耗 。 另 外 对 逻辑 (Logic) 部 分 会 根据 不 同 的 OPP 调节 电压 ， 而 对 memory 
部 分 则 没有 这 种 需求 ， 这 也 要 求 逻辑 和 存储 部 分 的 电源 分 离 。DPLL 部 分 也 在 两 个 voltage 
domain 中 ， 则 是 由 于 最 终 的 输出 时 钟 的 使 用 者 是 有 不 同 的 OPP， 如 果 整 个 DPLL 的 逻辑 完全 
支持 不 同 的 OPP， 设 计 复杂 度 要 高 ， 另 外 DPLL 的 时 钟 输入 没有 多 个 电压 规格 的 要 求 ， 这 样 
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图 2-5 voltage domain 和 power domain 关系 框图 


HEBES EF TE S8 AF HA PUE "T BE AN In], r DPLL 放 在 两 个 voltage domain 中 就 可 以 
起 到 隔离 的 作用 。 另 外 这 样 的 设计 可 以 降低 软件 的 复杂 度 ， 由 于 VDDI 和 VDD2 这 两 个 volt- 
age domain 的 状态 是 由 软件 管理 的 ， 如 果 DPLL 完全 放 和 人 这 两 个 voltage domain ， 意 味 着 软件 
要 完全 管理 DPLL 的 状态 ， 由 于 DPLL 本 身 的 状态 多 样 ， 而 且 管 理 该 模块 需要 很 多 硬件 的 知 
识 和 背景 ， 这 样 由 软件 管理 的 复杂 度 就 比较 高 。 如 果 设 计 中 将 其 分 离 ， 一 部 分 DPLL 的 开关 
逻辑 由 硬件 实现 ， 另 外 一 部 分 的 时 钟 和 所 连接 的 模块 在 一 个 voltage domain 中 ， 这 样 硬 件 中 
可 以 自动 处 理 一 些 电源 管理 的 功能 ， 以 简化 软件 设计 ， 这 也 是 综合 考虑 软件 和 硬件 的 结 
可 见 要 设计 好 的 系统 不 仅 要 考虑 硬件 的 实现 还 要 考虑 软件 如 何 控制 ， 如 果 软 件 复 杂 度 过 高 则 
说 明 系 统 的 耦合 度 高 ， 需 要 做 硬件 的 简化 隔离 来 降低 整个 系统 的 复杂 度 ， 同 样 在 板 级 设计 过 
程 中 也 要 考虑 软件 系统 设计 复杂 度 的 问题 ， 毕 竟 在 嵌入 式 系统 中 最 终 的 体验 和 稳定 性 是 软件 
和 硬件 整体 的 结 

看 了 图 2-5 之 后 ， 读 者 也 许 会 有 疑问 ， 既 然 power domain 的 电源 开关 是 可 以 控制 的 ， 那 
么 这 个 控制 模块 是 什么 ”又 在 哪个 power domain 中 呢 ? 其 实 图 2-4 已 经 给 出 了 基本 的 原理 ， 
所 有 power domain 的 控制 都 是 由 PRM 模块 执行 的 ，PRM voltage domain 和 power domain 由 
power Ctrl, idle/wakeup control 和 reset ctrl 三 个 控制 信号 连接 。power ctrl 信号 控制 voltage do- 
main 的 电源 输出 逻辑 ， 决定 是 否 为 对 应 的 power domain 输出 电源 ; idle/wakeup control 让 
power domain 中 的 模块 进入 idle 模式 或 者 唤醒 系统 ; reset ctrl 使 模块 进入 reset 状态 。 从 
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图 2-4 可 以 看 到 PRM 在 WKUP domain 中 。 这 个 很 好 理解 ， 这 里 使 用 反 证 法 证 明 ， 如 果 
PRM 不 在 WKUP domain 这 个 唯一 保持 清醒 的 power domain 中 ， 而 是 在 某 个 基本 power do- 
main 中 并 可 以 进入 待机 状态 ， 那 么 当 系统 需要 被 唤醒 的 时 候 ， 就 需要 一 个 模块 唤醒 PRM 所 
在 的 power domain, iX ELI PRM 管理 所 有 基本 power domain 这 种 设计 思想 相 矛 盾 ， 所 以 
PRM 必然 在 WKUP power domain 中 。 各 个 power domain, PRM 和 WKUP domain 之 间 的 详细 
关系 如 图 2-6 所 示 。 
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2-6 各 个 power domain 详细 关系 框图 





Al 2-6 5| H TI ÁJ (DM 3730 芯片 手册 》 中 第 280 页 框图 ， 从 中 可 以 看 到 所 有 的 power 
domain 以 及 WKUP domain 中 的 PRM 和 这 些 power domain 的 控制 关系 。 

(3) 引 脚 唤醒 

当 系 统 进 入 待机 状态 后 需要 能 从 外 部 唤醒 系统 。 这 就 需要 DM 3730 中 的 部 分 外 部 信号 
能 在 系统 进入 待机 状态 时 监测 外 部 信号 的 变化 。 之 前 说 明 中 提 到 ，WKUP domain 中 有 一 组 
GPIO 可 以 作为 外 部 的 唤醒 源 来 实现 唤醒 系统 的 功能 ， 但 是 只 有 一 组 GPIO 是 无 法 满足 需求 
的 ， 终 端 开 发 厂商 希望 外 部 接口 同样 有 唤醒 系统 的 功能 。 如 何 实现 呢 ， 笔 者 认为 DM 3730 
中 采用 了 比较 精巧 的 方法 ， 其 基本 原理 的 框架 如 图 2-7 所 示 。 
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KI 2-7 DM 3730 待机 管理 基本 原理 框 医 





























图 2-7 引 自 TL AY (DM 3730 芯片 手册 》 中 第 391 页 框图 。 当 系统 进入 待机 off 模式 时 ， 
引 脚 的 工作 模式 通过 pad off mode logie 来 接管 执行 ， 如 果 已 经 通过 System control module ( 主 
要 是 控制 引 脚 功能 的 模块 ) 使 能 待机 唤醒 事件 上 报 的 功能 ， 则 该 引 脚 会 检测 唤醒 事件 ， 一 
且 有 相应 的 事件 发 生 信和 号 就 会 通过 pad 形成 的 菊花 链 通知 一 直 清 醒 的 模块 (PROM 中 的 
PRM) ， 从 而 唤醒 系统 ， 系 统 被 唤醒 后 再 由 相应 的 驱动 程序 检查 是 否 由 事件 唤醒 系统 ， 如 果 
是 ， 则 要 进行 后 续 的 操作 。 可 见 这 里 硬件 提供 了 唤醒 系统 和 查询 状态 的 机 制 ， 具 体 实现 则 还 
是 依赖 软件 完成 ， 所 以 不 能 孤立 地 看 硬件 实现 ， 还 是 要 关注 软件 如 何 进行 操作 ， 提 供 一 个 方 
便 简单 的 操作 逻辑 对 系统 的 实现 以 及 其 稳定 性 都 至 关 重 要 。 

(4) 时 钟 管理 

至 此 ，PRCM 中 PRM 相关 的 功能 和 实现 方法 已 经 做 了 基本 介绍 ， 在 PRCM 中 还 有 一 部 
分 就 是 CM (Clock Management, 时 钟 管理 ) ， 这 部 分 主要 负责 各 个 模块 的 时 钟 产 生 ， 整 个 
DM 3730 的 时 钟 树 框 图 如 图 2-8 所 示 。 注 意图 2-8 是 示意 图 ， 从 中 基本 可 以 理解 时 钟 树 的 
Ex, 具体 的 实现 有 更 多 的 细节 ,但 是 层次 的 概念 是 相同 的 。 从 图 2-8 中 可 以 看 到 两 个 
voltage domain 分 别 是 wakeup voltage domain 和 core power domain, clock management 是 在 core 
voltage domain 中 ， 为 什么 CM 不 放 在 wakeup voltage domain PWE? 芯片 设计 人 员 这 样 设计 还 
是 为 了 能 够 降低 待机 功 耗 ， 毕 竟 管 理 所 有 clock 的 模块 复杂 度 不 会 太 低 ， 而 且 在 待机 状态 时 
外 设 模 块 都 应 该 关 掉 ， 这 样 把 CM 放 入 可 以 关 掉 的 core voltage domain 中 也 是 理所当然 的 。 
当然 wakeup voltage domain 中 的 PRM 要 执行 ， 同 样 需要 时 钟 ， 这 样 设计 时 就 将 外 部 的 晶振 或 
者 外 部 提供 的 时 钟 直接 接 人 PRM， 保 证 这 部 分 一 直 可 以 执行 。 另 外 图 2-8 中 可 以 看 到 CM 
的 输出 有 很 多 的 时 钟 ， 而 且 每 个 输出 时 钟 都 有 开关 可 以 控制 ， 这 些 时 钟 都 接 到 了 具体 的 模 
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块 ， 也 就 是 说 每 个 模块 的 输入 时 钟 都 可 以 控制 其 开关 ， 这 样 就 可 以 通过 软件 控制 设备 的 时 钟 
输入 ， 从 而 达到 较 好 的 电源 管理 效果 。 时 钟 管理 自然 也 是 电源 管理 框架 中 的 重要 一 环 ， 时 钟 
作为 设备 运行 的 必需 资源 需要 按 需 开关 ， 按 需 开 关 时 钟 在 设备 驱动 程序 中 是 非常 重要 的 
操作 。 
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图 2-8 ”时钟 树 示意 框 医 











具体 的 设备 模块 中 通常 会 有 两 种 时 钟 ， 一 种 是 interface clock (接口 时 钟 ， 通 常用 于 访 
问 寄存 器 ) ， 另 一 种 是 function clock (功能 时 钟 ， 主 要 是 模块 运行 需要 的 时 钟 )。 这 两 种 时 
钟 通常 可 以 单独 控制 ,设计 两 种 时 钟 是 因为 寄存 器 通常 对 模块 进行 设置 或 者 获取 其 状态 ， 而 
不 同 设备 的 功能 时 钟 频率 是 不 同 的 ， 如 果 使 用 同一 种 时 钟 ， 那 么 寄存 器 操作 这 部 分 就 要 针对 
每 个 设备 模块 单独 设计 ， 增 加 系统 复杂 度 。 
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至 此 ，DM 3730 电源 管理 相关 设计 介绍 完毕 ， 可 见 好 的 电源 管理 方案 设计 还 是 很 复杂 
的 ， 要 考虑 方方面面 的 问题 。 


2.2 DM 81XX 系列 微 处 理 器 


2010 年 TI 针对 DaVinci 品牌 系列 芯片 推出 了 DM 81XX 系列 芯片 ， 包 括 针 对 高 性 能 的 
DM 816X 系列 以 及 有 好 的 性 能 功 耗 比 的 DM 814X 系列 。 

DM 8168 视频 SoC 可 提供 业界 最 佳 的 视频 人 处理 性能， 同时 提高 了 多 通道 密度 ， 并 可 支持 
更 高 的 分 辨 率 。 此 外 ， 该 Soc 可 显著 提高 高 清 视频 的 预 处 理 与 后 处 理 功能 ， 实 现 前 所 未 有 的 
视频 性 能 ， 从 而 能 够 以 更 低 的 比特 率 支 持 更 高 质量 的 视频 ， 满 足 视 频 安 全 与 视频 通信 应 用 的 
需求 。 相 对 于 其 他 数字 视频 处 理 器 而 言 ， 该 SoC 支持 高 级 视频 分 析 与 增强 2D 与 3D 图 形 的 
能 力 ，DM 8168 视频 SoC 能 够 单 片 实现 十 六 通道 H. 264 等 多 视频 格式 DVR 功能 ， 从 而 可 显 
著 降低 DVR 系统 的 成 本 与 复杂 性 。 

DM 8148 视频 SoC 则 可 以 在 3W 功 耗 下 实现 1080P@ 60fps 的 视频 编码 能 力 ， 从 而 达到 较 
好 的 性 能 功 耗 比 ， 适 合 汽车 多 媒体 以 及 交通 和 安防 相机 等 应 用 。 

DM 81XX 系列 臣 片 的 应 用 范围 和 主要 处 理 器 见 表 2-2。 

表 2-2 DM 81XX 系列 芯片 应 用 范围 和 主要 处 理 单元 
















































































ARM 
芯片 型 号 应 用 范围 DSP 3D JI | 视频 加 速 TI 提供 编 解码 算法 
Cortex — A8 
安防 , 瘦 客 户 机 , 视频 会 议 ， H.264 BP/MP/HP, MPEG 
DM 8168 UN 1 1 1 3 HDVICPs 
可 视 电 话 -4, MPEG -2, JPEG/MJPEG 
"n H.264 BP/MP/HP, MPEG 
DM 8167 安防 , 视频 服务 器 1 1 3 HDVICPs 
-4, MPEG -2, JPEG/MJPEG 
e . H.264 BP/MP/HP, MPEG 
DM 8165 安防 , 视频 服务 器 1 1 2 HDVICPs 
-4, MPEG -2, JPEG/MJPEG 
安防 , 瘦 客 户 机 , 视频 会 议 ， H.264 BP/MP/HP, MPEG 
DM 8148 M 1 1 1 1 HDVICP 
可 视 电 话 -4, MPEG -2, JPEG/MJPEG 
] H.264 BP/MP/HP, MPEG 
DM 8147 安防 1 1 1 HDVICP 
-4, MPEG -2, JPEG/MJPEG 





























DM 81XX 主要 还 是 面向 视频 的 应 用 。 除 了 以 上 主要 的 应 用 范围 ，DM 81XX 还 可 应 用 在 
广电 领域 如 视频 转 码 服务 器 等 产品 上 。 男 外 由 于 DM 81XX 可 以 提供 丰富 的 视频 输出 接口 ， 
也 有 厂商 使 用 该 系列 芯片 实现 如 视频 矩阵 的 特殊 视频 应 用 。 总 之 ，DM 81XX 系列 芯片 可 以 
说 是 视频 SoC 的 王者 。 

2.2.1 DM 81XX 系列 微 处 理 器 框架 
DM 81XX 处 理 器 框架 有 DM 816X 系列 和 DM 814X 系列 。 
DM 816X 系列 处 理 器 框架 如 图 2-9 所 示 。 图 2-9 引 自 《DM 8168 芯片 数据 手册 》 第 5 


页 框图 。 
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图 2-9 DM 816X 系列 处 理 器 框 











DM 816X 有 六 种 核心 处 理 单元 : 

(D ARM Cortex - A8: 负责 系统 控制 和 外 围 接口 驱动 。Linux 运行 在 该 处 理 器 上 。 

@ DSP : 负责 信号 处 理 ， 可 以 实现 各 种 算法 如 图 像 识 别 等 。 

(3 SGX530: 负责 3D 泻 染 的 硬件 加 速 单元 (只 有 DM 8168 有 )。 

(4 HDVICP2: 负责 视频 编 解 码 处 理 ， 根 据 芯 片 型 号 会 有 2、3 个 HDVICP2 (DM 8168 和 
DM 8167 4 3 ^), 1 ^ HDVICP2 有 1080P@ 60fps 的 视频 编码 或 解码 能 力 。 

@ HDVPSS: 负责 处 理 视频 的 输入 和 输出 ， 可 以 处 理 多 路 复合 视频 输入 ， 如 4/8/16 路 
标清 输入 ， 显 示 输 出 最 多 可 以 有 4 路 同 源 的 输出 。 内 部 还 有 很 强 的 降 品 、 缩 放 、 去 隔行 等 
功能 。 

© Media Controller; 芯片 中 包含 两 个 ARM Cortex - M3 (作为 Media Controller), KAX} 
HDVICP2 以 及 HDVPSS 的 控制 和 管理 ， 主 要 是 为 了 解决 前 一 代 DaVinci AH ARM 或 者 
DSP 在 做 视频 处 理 时 负载 高 的 问题 。 有 了 Media Controller， 整 个 芯片 在 做 视频 编 / 解 码 和 视 
频 输入 输出 时 不 需要 ARM 和 DSP 的 干预 。 

主要 外 围 设备 的 接口 如 下 : 

(D EMAC ; 负责 以 太 网 连接 ， 最 多 支持 两 个 千 兆 以 太 网 。 

@ PCIe 2.0; 负责 PCI 总 线 连接 ， 可 以 连接 PCI 设备， 也 可 以 作为 PCI 扩展 设备 与 X86 
处 理 器 连接 。 

(3 SATA : 负责 SATA 接口 处 理 ， 通 常用 来 与 SATA 硬盘 连接 。 
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(4) USB 2.0 Ctrl and PHY; 负责 USB 的 连接 ， 此 接口 为 USB OTG 接口 。 

®© DDR2 and DDR3: 负责 DDR memory 的 连接 ， 芯 片 包含 两 个 32 bit DDR 接口 ， 可 以 提 
高 整体 的 DDR 吞 叶 量 。 

© GPMC and ELM; 负责 各 种 Flash 存储 器 的 连接 ， 该 接口 可 以 通过 时 序 编 程 与 FPCA 
进行 连接 以 扩展 功能 。 

D Peripherals : 各 种 外 设 接口 如 UART ( $H J rc (通常 负责 传感器 的 控制 ) 、McASP 
fil McBSP. (负责 音频 数据 传输 ) SD 和 SDIO (负责 SD 卡 或 者 WIFI 芯片 的 连接 ) 等 。 

GP Timer; 可 编程 的 定时 器 ， 向 系统 提供 定时 功能 。 

除去 以 上 还 有 以 下 模块 ， 

(D EDMA : 负责 数据 在 外 设 和 内 存 或 者 内 存 不 同 区 块 之 间 的 复制 ， 用 来 降低 处 理 器 的 
负载 以 提高 系统 性 能 。 

© On - Chip RAM ; rJ RAM, 使 系统 在 外 部 内 存 没有 初始 化 好 的 情况 下 仍 可 运行 。 
通常 该 段 内 存 可 用 于 系统 初始 化 、 系 统 加 速 等 。 注 意 DM 816X 系列 芯片 内 部 有 512KB 片 内 
RAM， 这 么 大 的 容量 可 以 放 很 多 内 容 ， 比 如 在 系统 初始 化 的 时 候 很 多 芯片 由 于 片 内 RAM 的 
容量 限制 需要 u-boot 作为 二 级 引导 程序 ， 而 DM 816X 则 可 以 将 u-boot 直接 作为 一 级 引导 程 
序 ， 从 而 减少 系统 启动 时 间 ， 相 应 的 u-boot 需要 初始 化 DDR 控制 器 。 

(3) System Interconnect : 片 内 总 线 ， 负 责 在 片 内 各 个 模块 间 建 立 通道 。 

DM 814X 系列 处 理 器 框架 如 图 2-10 所 示 。 图 2-10 引 自 《DM 8148 芯片 数据 手册 》 第 
5 页 框图 。 
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DM 814X 有 七 种 核心 处 理 单元 : 

(D ARM Cortex - Ms 负责 系统 控制 和 外 围 接口 驱动 。Linux iS £3 YEVA A Pss E; 

@ DSP : 负责 信号 处 理 ， 可 以 实现 各 种 算法 如 图 像 识 别 等 。 

SCs Oe JUR 3D Ti i (RE DM 8148 40), 

@ HDVICP2; 负责 视频 编 解码 处 理 ，1 个 HDVICP2 有 1080P@ 60fps 的 视频 编码 或 解码 
能 力 。 

(5) Video Processing Subsystem ( VPSS) : 负责 处 理 视频 的 输入 和 输出 ， 可 以 处 理 多 路 复 
合 视频 输入 ， 如 4/8/16 路 标清 输入 ， 显 示 输 出 最 多 可 以 有 4 路 同 源 的 输出 。 内 部 还 有 很 强 
的 降 品 、 缩 放 、 去 隔行 等 功能 。 

© Imaging Subsystem (ISS) ; 负责 Camera Sensor 的 接 入 ， 可 以 接 入 Bayer Patter Raw 格 
式 数 据 ， 其 中 包含 ISP (Image Sensor Process ) 模块 ， 可 以 进行 图 像 处 理 ， 另外 ISP 中 包含 
3A (Auto Focus, Auto White Balance, Auto Expose) 统计 模块 ， 通 过 3A 统计 进行 图 像 参 数 
的 调整 以 达到 最 佳 的 图 像 效果 。 

@ Media Controller; 其 芯片 中 包含 两 个 ARM Cortex - M3 (作为 Media Controller) ， 实 现 
对 HDVICP2 以 及 VPSS 和 ISS 的 控制 和 管理 。 

主要 外 围 设备 的 接口 如 下 : 

(D EMAC; 负责 以 太 网 连接 。 

(2) PCIe 2.0: 负责 PCI 总 线 连 接 ， 可 以 连接 PCI 设备 也 可 以 作为 PCI 扩展 设备 与 X86 处 
理 器 连接 。 

@ SATA : 负责 SATA 接口 处 理 ， 通 常用 来 与 SATA 硬盘 连接 。 

(4) USB 2.0 Ctrl and PHY; 负责 USB 的 连接 ， 此 接口 为 USB OTG 接口 。 

®© DDR2 and DDR3: 负责 DDR memory 的 连接 ， 芯 片 包含 两 个 32bit DDR 接口 ， 可 以 提 
高 整体 的 DDR FEE, 

© GPMC and ELM; 负责 各 种 Flash 存储 器 的 连接 ， 该 接口 可 以 通过 时 序 编程 与 FPGA 
进行 连接 以 扩展 功能 。 

D DCAN: 负责 CAN 总 线 连接 ，CAN 总 线 扩展 适合 工业 和 汽车 应 

Dori cm c E 传感器 的 控制 )、 
McASP 和 McBSP (负责 音频 数据 传输 )、SD 和 SDIO (负责 SD 卡 或 者 WIFI 芯片 的 连 
接 ) 等 。 

(9) GP Timer; 可 编程 的 定时 器 ， 向 系统 提供 定时 功能 。 

除去 以 上 还 具有 同 DM 816X 相关 部 分 相同 模块 。 


2.2.2 DM 81XX 系列 微 处 理 器 特性 


DM 816X 系列 处 理 需 主要 特性 : 

e 对 混合 型 安防 DVR 解决 方案 而 言 ， 可 同时 支持 16 通道 D1 的 H. 264 HP 编码 并 附带 
CIF 子 码 流 的 编码 与 8 通道 D1 解码 ， 并 具有 视频 混合 与 图 像 混合 功能 ， 文 持 多 达 三 
个 独立 显示 器 。 

e 对 视频 通信 应 用 而 言 ， 可 同时 支持 三 个 1080P@ 60fps 视频 编码 或 解码 ， 由 于 编 解 
码 器 延 时 低 于 50 ms， 因 此 片 外 失效 问题 得 以 消除 ， 从 而 可 将 点 对 点 延 时 降 至 50 ms 
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以 下 。 

e 极 高 的 集成 度 ， 集 成 1 GHz ARM Cortex - A8, 1 GHz TI C674x DSP、 两 个 可 编程 高 清 
视频 影像 协 处 理 器 、 一 个 创新 型 高 清 视频 处 理子 系统 以 及 综合 编 解码 器 (支持 包括 高 
清 分 辩 率 的 H. 264, MPEG -4 以 及 VC1)。 

e 包括 千 兆 以 太 网 、PCI Express, SATA2, DDR2, DDR3, USB 2.0, MMC/SD, HDMI 
以 及 DVI 等 多 种 接口 ， 可 支持 高 度 灵 活 的 设计 方案 实施 。 

e 无 颖 接口 连接 至 四 个 TI 的 多 通道 视频 解码 器 TVP5158 ， 可 无 颖 捕获 多 达 十 六 个 D1 视 
频 通 道 。TVP5158 可 自动 控制 对 比 度 ， 降 低 噪声 ， 提 高 压缩 比 与 整体 视频 质量 ， 从 而 
不 但 可 取消 额外 的 FPGA 与 外 部 存储 器 ， 还 可 简化 设计 ， 提 高 系统 灵活 性 。 

e 提供 1.8V/3.3V LO 电压 ， 适 合 工业 应 用 。 

DM 814X 系列 处 理 器 主要 特性 基本 同 DM 816X， 编 解码 性 能 方面 为 一 个 1080P@ 60fps 

视频 编码 或 解码 ， 附 加 的 特性 如 下 : 

e 内 部 实现 ISP 可 以 实现 图 像 色 彩 还 原 、 图 像 增强 、 视 频 稳定 以 及 变焦 失真 校正 等 影像 
信号 处理 技术 。 

e 可 实现 高 级 运动 补偿 低 照 技术 ， 可 以 在 极 低 光线 环境 下 实现 清晰 的 影像 画 质 。 

e 集成 CAN 总 线 控制 器 ， 可 以 扩展 到 汽车 上 的 图 像 应 用 。 


2.2.3 DM 81XX 系列 微 处理 需 电源 管理 相关 设计 


1. DM 81XX 使 用 的 电源 管理 技术 介绍 

在 电源 管理 设计 方面 ，DM 816X 和 DM 814X 也 是 通过 PREM 模块 实现 电源 管理 功能 的 ， 
但 是 DM 816X 和 DM 814X 中 PRCM 使 用 的 电源 管理 技术 是 不 同 的 。 在 讲 DM 3730 电源 管理 
时 提 到 过 两 种 基本 的 电源 管理 技术 DVFS 和 AVS， 由 于 DM 816X 更 多 面向 高 性 能 的 设备 需 
求 ， 所 以 在 电源 管理 技术 中 选择 了 AVS, M DM 814X 的 需求 是 获得 最 大 的 能 耗 比 ， 所 以 在 
电源 管理 技术 方面 选择 了 DVFS。 而 对 完全 待机 的 模式 (off HEEL) ， 两 个 系列 芯片 都 省 略 了 
该 功能 ， 以 降低 PROM 的 复杂 度 。 可 见 电源 管理 技术 的 使 用 还 是 要 根据 需求 进行 选择 和 实 
施 ， 这 样 才 能 设计 出 有 良好 性 价 比 的 芯片。 

2. DM 81XX 电源 管理 模块 详解 

电源 管理 PRCM 中 voltage domain 和 power domain 的 实现 ,在 DM 816X 和 DM 814X 两 个 
系列 芯片 中 的 设计 也 是 不 同 的 。 

DM 816X 中 voltage domain 和 power domain 的 关系 如 图 2-11 Pras, Al2-11 5| E. (DM 
8168 芯片 手册 》 中 第 1788 页 框图 。 框 图 中 下 半 部 分 的 表格 说 明 图 中 各 个 颜色 属于 哪个 volt- 
age domain 和 power domain， 其 中 列表 示 的 是 voltage domain， 而 行 表 示 的 是 power domain, 
从 框图 中 可 以 看 到 不 同 模 块 的 逻辑 部 分 和 存储 部 分 还 是 采用 不 同 的 电压 。 在 voltage domain 
中 有 一 个 是 1V AVS， 这 个 1V AVS voltage domain 就 是 指使 用 AVS 技术 ， 其 电压 规格 是 1V 
的 voltage domain。 框 图 中 主要 的 处 理 模块 (如 ARM、DSP、HDVPSS 和 HDVICP 等 ) 和 主要 
的 外 部 接口 (如 PCIe、SATA 等 ) 都 在 1V AVS voltage domain 中 ， 可 以 说 整个 芯片 的 逻辑 部 
分 都 在 1V AVS 的 管理 下 ， 这 样 设计 可 以 最 大 限度 地 降低 整个 心 片 的 功 耗 ， 在 技术 和 实际 效 
果 中 取得 一 个 好 的 平衡 。 从 power domain 来 看 DM 816X， 可 以 看 到 有 个 Always - on power 
domain, ， 该 power domain 会 在 上 电 后 电源 处 于 常 开 状 态 ，Always - on power domain 中 包括 
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ARM 和 大 部 分 外 设 接口 ， 从 芯片 设计 的 角度 是 简化 了 许多 。 
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图 2-11 DM 816X 的 voltage domain 和 power domain 关系 框图 


下 面 看 看 DM 814X 中 voltage domain 和 power domain 的 关系 ， 如 图 2-12 所 示 。 

图 2-12 引 自 《DM 8148 芯片 手册 》 中 第 487 页 框图 。 从 中 可 以 看 出 DM 814X 的 voltage 
domain 和 power domain 的 关系 ，power domain 中 逻辑 相关 的 部 分 在 一 个 voltage domain 中 ， 而 
memory 存储 相关 的 部 分 在 另外 一 个 voltage domain 中 。DM 814X 的 power domain 信息 以 及 其 
中 包含 的 具体 模块 见 表 2-3。 
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LEGEND 
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图 2-12 DM 814X 的 voltage domain 和 power domain 的 关系 框图 





KR 2-3 DM 814X Power Domain 信息 及 模块 说 明 
电 源 域 模 块 





Cortex™ — A8, DCANO, DCANI, DDR_PHY_LOGICO, DDR_PHY_LOGIC1, DMM EDMA, 
ELM, EMIFO, EMIFI , 2Channel GMAC Switch, GPIO_CNTLO, GPIO_CNTLI , GPIO. CNTI2, 
GPIO_ CNTI3, GPMC, I2C0, I2C1, I2C2, I2C3, Interconnect, IPC, MCASPO, MCASPI, 
ALWAYS ON MCASP2, MCASP3, MCASP4, MCASP5, ATL, MCBSP, MLB, OCMC SRAM, PATA, PBIST, 
PCI, PRCM, RTC, SATA, SCR, SD/MMCO, SD/MMCI ,SD/MMC2, SPIO, SPI1, SPI2, SPB, 
Switch fabric, Timerl, Timer2, Timer3, Timer4, Timer5, Timer6, Timer7, Timer8, UARTO, 
UARTI , UART2, UART3, UART4, UARTS, USBO,USBI , WDTO, VCP, XBAR, Debug SS 

















ISS (ISP) FACEDETECT, ISS 
SGX530 SGX530 Subsystem 
DSS HDD, SS, HDMI, SD - DAC LOGC 
ACTIVE ( DSP) C674x + ™ Subsystem. , C674x + ™ 12 SRAM 
HDVICP HDVICP, SRSense2 





DM 816X 和 DM 814X 的 内 部 时 钟 设计 和 DM 3730 相 比 也 做 了 精简 。 有 很 多 模块 共用 同 
一 个 时 钟 ， 而 不 像 DM 3730 那样 每 个 模块 都 有 自己 的 时 钟 。 

DM 816X 系统 内 部 时 钟 信 息 见 表 2-4。 

DM 816X 的 外 部 主要 时 钟 输入 是 27 MHz， 但 是 从 表 中 可 见 SYSCLK18 是 32 kHz， 这 是 
为 DM 816X 中 包含 一 个 RTC， 这 个 32kHz 是 为 RTC 提供 的 ， 而 不 是 像 DM 3730 中 为 整个 
系统 待机 时 使 用 ， 同 样 的 时 钟 源 其 使 用 方法 也 会 因为 需求 的 变化 而 不 同 。 

DM 814X 的 时 钟 框架 如 图 2-13 所 示 。 从 中 可 以 看 出 时 钟 框架 同样 做 了 类 似 DM 816X 的 
精简 ， 一 个 系统 时 钟 会 对 应 多 个 模块 。 其 中 也 有 奇怪 的 现象 ， 比 如 有 OSCO 和 OSCI 两 个 时 
钟 源 ， 而 且 0SC0 是 20 MHz 固定 的 ， 而 OSCI 是 20 ~30 MHz 之 间 的 ， 这 样 设计 是 为 了 音频 
和 视频 的 精度 ， 比 如 音频 通常 是 44. 1 kHz 采样 频率 。 通 过 两 个 时 钟 源 就 可 以 提高 音频 采样 
的 精度 ， 提 高 音频 质量 ， 也 就 从 整体 上 提升 产品 质量 。 
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322-4 DM 816X 内 部 时 钟 信息 






























































时 钟 频 率 描述 

SYSCLKI1 1 GHz To C674x DSP 

SYSCLK2 1.2 GHz To Cortex — A8 

SYSCLK3 600 MHz To HDVICP2 

SYSCLK4 500 MHz Interconnect Clock, Clock for HD DSS, TPTCs, TPCC, DMM 

— — Interconnect Clock, SGX530, USB SS, 10/100/1000 EMAC, SATA, PCIe, OC- 
MC RAM 

— suns Interconnect Clock, UART, PC, SPI, SDIO, TIMER, GPIO, McASP, McBSP, 
GPMC 

SYSCLK7 125 MHz( maximum) Reserved 

SYSCLK8 800 MHz DDR clock 

SYSCLK9 48 MHz Reserved 

SYSCLK10 48 MHz SPI. PC, SDIO, and UART functional clock 

SYSCLK11 216 MHz Reserved 

SYSCLK13 165 MHz( maximum) HDVPSS 

SYSCLK14 27 MHz Reserved 

SYSCLK15 165 MHz( maximum) HDVPSS 

SYSCLK16 27 MHz Reserved 

SYSCLK17 54 MHz HDVPSS 

SYSCLK18 32 kHz RTC 

SYSCLK19 62. 5 MHz Reserved 

MCASPO, CLK McASPO AUX Clock 





MCASP1_CLK 


McASPI AUX Clock 





























MCASP2_CLK McASP2 AUX Clock 
MCBSP_CLK McBSP AUX Clock 
TIMER1_CLK Timer clock for Timer 1 
TIMER2_CLK Timer clock for Timer 2 
TIMER3_CLK Timer clock for Timer 3 
TIMER4_CLK Timer clock for Timer 4 
TIMERS _CLK Timer clock for Timer 5 
TIMER6_CLK Timer clock for Timer 6 
TIMER7_CLK Timer clock for Timer 7 

















至 此 DM 81XX 电源 管理 相关 设计 就 介绍 完毕 ， 可 见 设计 要 从 需求 出 发 ,考虑 最 佳 性 


价 比 。 
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MCASP, MCBSP. HDMI, ATL HL 
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RTC, GPIO, ARM, CLK32K for MMCO,1,2 
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clkin32 pin (option 
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2-13 DM 814X 时 钟 框架 











2.3 Sitara 系列 芯片 


笔者 看 到 一 篇 很 好 的 关于 处 理 器 的 文章 是 王 齐 的 《ARM 与 X86》。 在 这 里 介绍 给 读者 ， 

其 中 可 以 了 解 到 ARM 和 X86 两 种 不 同 架构 的 发 展 史 ， 在 ARM 的 发 展 中 TE 一 直 是 幕后 英雄 ， 

ARM 真正 的 发 展 是 依赖 于 TI 与 Nokia 合作 的 无 线 终端 芯片 的 发 展 。 但 是 2009 年 之 前 TI 对 

ARM 的 使 用 都 是 在 无 线 终端 和 视频 芯片 范围 内 ， 并 没有 像 三 星 、ST 等 推出 纯 ARM 的 产品 。 
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这 个 格局 在 2010 年 被 打破 了 ， 面 对 广阔 的 能 入 式 控 制 市 场 ，TI 在 2010 年 之 后 推出 了 一 系列 
纯 ARM 的 处 理 器 产品 即 Sitara 系列 微 处 理 器 。 既 然 开 已 经 在 无 线 终端 和 视频 芯片 中 使 用 了 
ARM， 那 么 最 简单 的 推出 纯 ARM 处 理 器 的 方法 就 是 在 无 线 终端 和 视频 芯片 的 基础 上 精简 ， 
去 除 不 使 用 的 协 处 理 器 。 这 样 做 的 好 处 很 明显 ， 没 有 开发 的 费用 ， 而 且 和 相应 的 芯片 引 脚 兼 
容 ， 方便 垦 入 式 设备 开发 商 在 一 个 平台 开发 多 种 类 型 产品 。 具 体 Sitara 系列 芯片 应 用 说 明 见 
表 2-5。 




















表 2-5 Sitara 系列 芯片 应 用 说 明 



































































































































































































































芯片 型 号 立 用 范围 a os 
Cortex — A8 Supply( V) 
AM 3894 | 通信 和 电信 ， 计 算 机 及 外 设 ， 工 业 ， 医 疗 1 1 1.5, 1.8,3.3 
AM 3892 | 通信 和 和 电信， 计算 机 及 外 设 ， 工业， 医疗 1 1.5, 1.8, 3.3 
AM 3874 | 通信 和 电信 ， 计 算 机 及 外 设 ， 工 业 ， 医 疗 1 1 1.5, 1.8, 3.3 
AM 3871 | 通信 和 电信 ， 计 算 机 及 外 设 ， 工 业 ， 医 疗 1 1.5, 1.8, 3.3 
AM 3715 | 消费 性 电子 ， 工 业 ， 医 疗 1 1 1.8 
AM 3703 | 消费 性 电子 ， 工业， 医疗 1 1.8 
AM 3517 | 消费 性 电子 工业， 医疗 1 1 1.8, 3.3 
AM 3505 | 消费 性 电子 ， 工业， 医疗 1 1.8, 3.3 
AM 3359 | 连接 自动 贩卖 机 ， 家 庭 /楼 宇 自动 化 ， 消 费 类 电子 产品 1 1 1.8, 3.3 
AM 3358 | “便携式 导航 ， 连 接 自动 贩卖 机 ， 家 庭 / 楼 宇 自动 化 ， 消 费 类 电子 产品 1 1 1.8, 3.3 
AM 3357 | ”便携式 导航 ， 连 接 自动 贩卖 机 ， 家 庭 / 楼 宇 自动 化 ， 消 费 类 电子 产品 1 1,8,.3.3 
AM 3356 | 连接 自动 贩卖 机 ， 家 庭 / 楼 宇 自动 化 ， 消 费 类 电子 产品 1 1.8, 3.3 
AM 3354 | ”便携式 导航 ， 连 接 自动 贩卖 机 ， 家 庭 / 楼 宇 自动 化 ， 消 费 类 电子 产品 1 1 1.8, 3.3 
AM 3352 | 连接 自动 贩卖 机 ， 家 庭 /楼 宇 自动 化 ， 消 费 类 电子 产品 1 1.8, 3.3 




















dé 2-5 中 AM 3894 和 AM 3892 是 从 DM 816X 系列 芯片 精简 得 来 的 ，AM 3874 和 AM 
3871 是 从 DM 814X 系列 芯片 精简 得 来 的 ，AM 3715 和 AM 3703 是 从 DM 3730 系列 芯片 精简 
得 来 的 。 

由 于 无 线 终端 芯片 和 视频 芯片 开发 周期 较 长 ， 成 本 较 高 ， 一 味 的 采用 精简 的 方式 并 不 能 
适应 对 开发 周期 和 成 本 要 求 都 比较 高 的 消费 类 ARM 的 市 场 。 为 了 适应 相应 的 市 场 需求 ，TI 
于 2011 年 推出 了 AM 335X 系列 处 理 器 ，Cortex - A8 的 核心 最 低 价格 低 于 5 美元， 性价比 还 
是 很 高 的 。 


2.3.1 Sitara 系列 心 片 框架 


由 于 部 分 Sitara 芯片 是 从 对 应 的 无 线 终端 芯片 和 视频 芯片 精简 而 来 的 ， 这 里 就 重点 介绍 
AM 335X 系列 处 理 器 的 框架 

AM 335X 系列 处 理 器 框架 如 图 2-14 所 示 。 图 2-14 引 自 《AM 335X 芯片 数据 手册 》 第 
6 页 框图 。 

AM 335X 有 五 种 核心 处 理 单元 : 

(D ARM Cortex - A8: 负责 系统 控制 和 外 围 接口 驱动 。Linux 运行 在 该 处 理 器 上 。 
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图 2-14 AM 335X 系列 处 理 器 框 医 











(2) PowerVR SGX; 负责 3D 演 染 的 硬件 加 速 单元 。 
(3) Display: 负责 处 理 视频 的 显示 输出 。 
@ Crypto: 负责 加 密 算法 的 加 速 处 理 单元 。 
©) PRU -ICSS: 可 编程 单元 实现 对 引 脚 的 管理 ， 从 而 可 以 根据 需要 模拟 不 同 的 接口 功 
实现 类 似 FPGA 的 功能 。 
主要 外 围 设备 的 接口 如 下 : 
(D EMAC; 负责 以 太 网 连接 ， 最 多 支持 两 个 干 兆 以 太 网 。 
2) USB 2.0HS OTG + PHY: 负责 USB 的 连接 ， 此 接口 为 USB OTG 接口 。 
(3) Memory Interface; 负责 DDR memory 内 存 的 连接 ， 以 及 Flash 存储 器 的 连接 。 
(4) Peripherals; 各 种 外 设 接 口 如 UART ($0), PC (通常 负责 传感器 的 控制 )， 
McASP (负责 音频 数据 传输 ) ，SD 和 SDIO (负责 SD 卡 或 者 WIFI 芯片 的 连接 ) 等 。 
© GP Timer; 可 编程 的 定时 器 ， 向 系统 提供 定时 功能 。 
除去 以 上 还 有 以 下 模块 : 
(D eDMA: 负责 数据 在 外 设 和 内 存 或 者 内 存 不 同 区 块 之 间 的 复制 ， 用 来 降低 处 理 絮 的 负 
载 以 提高 系统 性 能 。 
(2) 64K Shared RAM: 片 内 RAM， 使 系统 在 外 部 内 存 没有 初始 化 好 的 情况 下 仍 可 运行 。 
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通常 该 段 内 存 可 用 于 系统 初始 化 、 系 统 加 速 等 。 
(3) L3 and LA Interconnect; 片 内 总 线 ， 负 责 在 片 内 各 个 模块 间 建 立 通道 。 


2.3.2 Sitara 系列 芯片 特性 


从 对 应 的 无 线 终端 芯片 和 视频 芯片 精简 而 来 的 Sitara 芯片 的 特性 之 前 已 经 有 所 了 解 ， 这 
里 重点 介绍 AM 335X 系列 处 理 器 ， 其 特性 如 下 . 

e AM 335x ARM Cortex - A8 微 处 理 器 适用 于 工业 自动 化 设计 ， 提供 可 编程 实时 单元 
(PRU) 片上 接口 ， 可 实现 实时 工业 通信 (EMA), XIF EtherCAT @®、Ethernet/IP、 
PROFIBUS (B, PROFINET (&, POWERLINK 以 及 SERCOS III 等 常见 协议 。AM 335x 
ARM 微 处 理 器 中 这 种 独特 的 PRU + ARM 架构 无 需 外 部 ASIC 或 FPGA， 可 降低 系统 
复杂 性 ， 节 和 省 超过 30% 的 材料 清单 (BOM) 成 本 。 此 外 ，AM 335x ARM 微 处 理 器 还 
包含 其 他 重要 片上 工业 外 设 (CAN、ADC、USB + PHY 以 及 双 端 口 千 兆 以 太 网 
IEEE1588) ， 不 但 文 持 快速 网 络 连接 与 快速 数据 吞吐 ， 而 且 还 可 连接 传感器 、 传 动 需 
以 及 电机 控制 。 

e 支持 众多 不 同 终端 设备 的 统一 可 扩展 平台 ,设计 人 员 可 充分 利用 ARM Cortex - A8 fik 
处 理 右 的 引 脚 以 及 软件 兼容 性 ， 采 用 最 符合 工业 自动 化 需求 的 器 件 设计 不 同 的 终端 
设备 。 

芯片 上 提供 高 级 3D 图 形 功能 、 触 摸 屏 控制 器 以 及 高 级 外 设 ， 为 开发 人 员 提 供 高 性 能 
的 基础 上 缩减 板 级 空间 ， 降 低 设计 复杂 性 ， 并 可 将 材料 清单 (BOM) 成 本 锐 降 40 美 
元 ， 从 而 充分 满足 便携 式 导 航 、 掌 上 游戏 及 教育 设备 ， 以 及 家 庭 及 楼 宇 自动 化 等 更 小 
型 应 用 的 需求 。 


2.3.3 Sitara 系列 心 片 电源 管理 相关 设计 


在 电源 管理 方面 ， 仍 以 AM 335X 的 实现 为 主 进行 介绍 。 

1. AM 335X 使 用 的 电源 管理 技术 介绍 

由 于 AM 335X 需要 满足 便携 式 消费 电子 产品 的 需求 ， 所 以 在 电源 管理 技术 方面 使 用 了 
DVFS 和 AVS。 男 外 AM 335X 也 允许 系统 进入 完全 待机 状态 ， 和 DM 3730 不 同 的 是 待机 时 
AM 335X 功 耗 大 概 3mW 左右 。3 mW 的 待机 功 耗 虽然 无 法 和 DM 3730 的 0.1mW 相 比 ， 但 是 
普通 的 便携 设备 也 是 可 以 接受 的 。 

2. AM 335X 电源 管理 模块 详解 

AM 335X 在 电源 管理 的 实现 虽然 使 用 的 技术 是 全 面 的 ， 但 是 如 果 和 DM 3730 在 PRCM 
的 实现 进行 比较 ，AM 335X 的 实现 还 是 做 了 比较 多 的 精简 。 完 全 待机 3 mW 功 耗 也 能 看 出 这 
种 精简 的 结果 。 

在 voltage domain 实现 方面 ，AM 335X 实现 了 两 个 voltage domain 分 别 是 VDD_CORE 和 
VDD_RTC。 所 有 核心 模块 都 放 在 了 VDD_CORE 中 ， 只 要 将 RTC 这 个 需要 单独 供电 的 模块 放 
入 VDD_RTC 中 ， 就 能 保证 RTC 在 其 他 模块 下 工作 的 情况 下 仍然 可 以 工作 ,确保 时 间 的 
准确 。 

在 power domain 实现 方面 ，AM 335X 实现 了 多 个 power domain; 为 了 能 唤醒 系统 提供 了 
WKUP power domain, ARM 单独 是 一 个 power domain 称 作 MPU power domain; RTC 在 RTC 
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power domain 中 ; 大 部 分 外 设 则 在 PER power domain 中 。 和 DM 3730 —FE, WKUP 还 包含 一 
些 外 设 模块 ， 可 以 用 来 唤醒 系统 ， 但 是 为 了 设计 的 简单 ， 并 未 实现 WKUP domain 之 外 模块 
通过 L/O 唤醒 系统 ， 这 样 就 又 比 DM 3730 设计 简单 了 许多 。 

在 时 钟 管理 方面 ，AM 335X 直接 通过 Core PLL 分 频 出 几 个 时 钟 供 大 部 分 的 外 设 模块 使 
用 。Core PLL 的 时 钟 树 如 图 2-15 所 示 ， 图 2-15 引 自 《AM 335X 芯片 手册 》 中 第 893 页 框 
图 ， 从 图 中 可 以 看 出 其 输出 有 限 的 几 个 时 钟 如 L3 F_CLK \L3S_CLK 等 ，Core PLL 的 时 钟 输出 
与 各 外 设 模块 的 对 应 关系 见 表 2-6。 
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图 2-15 AM 335X Core PLL 时 钟 树 


# 2-6 Core 时 钟 输出 对 应 的 设备 模块 
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IEEE1588v2) 
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(Enat switch bus 
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inf oo a 模 块 
L3F_CLK GEMAC Switch ( Ethernet) , DAP, PRU - ICSS, EMIF, TPTC, TPCC, OCMC RAM, DEBUGSS 
L3S CLK USB, TSC, GPMC, MMCHS2, McASPO, McASPI 
DCANO, DCANI,DMTIMER2, DMTIMER3, DMTIMER4, DMTIMERS, DMTIMER6, DMTIMER7, 
BER OPE eCAP/eQEP/ePWMO, eCAP/eQEP/ePWMI , eCAP/eQEP/ePWM2, eFuse, ELM, GPIOI, GPIO2, 
i ~ GPIO3 I2C1, I2C2, IEEEI500, LCD, Mailbox0, McASPO, McASP1 ,MMCHSO, MMCHSI , OCP Watch- 
point SPIO, SPI1, Spinlock, UART1, UART2, UART3, UART4, UARTS 
ADC _ TSC, Clock Manager, Control Module, DMTIMERO, DMTIMERI _ IMS, GPIOO, I2C0, 
I4 WKUP CLK 
M3UMEM, M3DMEM, SmartReflex0 , SmartReflexl , UARTO, WDTI 





系统 中 还 有 一 些 时 钟 (如 ARM 的 时 钟 ) 也 是 通过 类 似 Core PLL 的 方式 由 PLL 输出 的 ， 
这 里 就 不 再 歼 述 ， 具 体 细节 可 见 《AM 335X 芯片 手册 》 第 8.1.6 节 。 
在 WKUP 的 设计 中 ，AM 335X 在 待机 和 唤醒 控制 方面 ， 通 过 将 Cortex - M3 JA. WKUP 
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domain 中 ， 然 后 采用 软件 控制 的 方式 实现 相应 的 功能 ， 没 有 像 DM 3730 那样 直接 用 硬件 实 
现 复杂 的 控制 逻辑 。 相 对 于 硬件 来 说 软件 开发 成 本 较 低 ， 将 这 部 分 用 成 熟 核心 和 软件 共同 实 
现 ， 可 以 提高 硬件 的 稳定 性 ， 降 低 成 本 ,虽然 效果 没有 单独 设计 硬件 好 ,但 是 综合 下 来 在 满 
足 需 求 的 情况 下 ， 该 实现 方案 还 是 很 有 优势 的 。 

从 AM 335X 电源 管理 的 设计 细节 可 以 看 出 技术 方案 还 是 多 种 多 样 的 。 符 合 需求 ， 性 价 
比 好 才 是 最 好 的 ,“ 只 选 对 的 ， 不 选 贵 的 ”在 设计 中 也 非常 适用 。 





2.4 TI 处 理 器 内 核 特殊 代码 结构 


在 Linux 中 ,体系 结构 相关 的 代码 都 在 arch 目录 下 。 之 前 介绍 的 TI 处 理 器 都 属于 ARM 
体系 结构 。 在 arch/arm 目录 下 ， 和 TI 处 理 器 相关 的 日 录 有 mach - davinci、mach - omapl , 
mach - omap2, plat -omap。 这 些 目录 相关 的 说 明 见 表 2-7。 

表 2-7 TI 处 理 器 内 核 特殊 代码 目录 说 明 

目 录 说 明 














的 文件 是 以 ARM9 为 核心 的 DaVinci 处 理 器 (如 DM 6446, DM 36X 和 DM 6467) 的 设 
备 相 关 的 底层 代码 


mach - davinci 








该 目录 中 的 文件 是 第 一 代 OMAP 处 理 器 的 设备 相关 的 底层 代码 〈 该 目录 处 理 器 已 经 过 时 ， 很 少 











mach — omapl 
































的 文件 是 OMAP2/OMAP3/OMAP4/OMAPS 处 理 器 和 新 一 代 DaVinci 处 理 器 (DM 81XX 
系列 处 理 器 ) 的 设备 相关 的 底层 代码 


plat - omap 该 目录 中 的 文件 是 为 驱动 抽象 出 来 的 各 种 与 设备 无 关 的 统一 接口 ， 用 以 减少 系统 耦合 度 





mach — omap2 



























































表 2-7 中 有 一 个 奇怪 的 现象 ， 新 一 代 DaVinci 处 理 器 的 代码 不 是 在 mach - davinci 中 ， 
而 是 在 mach - omap2 中 。 这 看 似 奇怪 的 问题 ， 可 以 换个 角度 来 考虑 ， 既 然 把 它们 放 到 一 起 
必定 是 有 原因 的 ， 这 个 原因 是 什么 呢 ? 老话 常 阅 “ 物 以 类 聚 ， 人 以 群 分 ”， 软 件 也 不 例 
外 ， 放 到 一 起 的 代码 相似 度 也 要 高 一 些 。 从 这 个 角度 考虑 ， 新 一 代 DaVinci 心 片 应 该 和 
OMAP2 及 以 后 的 OMAP 处 理 器 在 芯片 内 部 结构 方面 相似 度 更 高 一 些 。 之 前 介绍 DM 3730, 
DM 81XX 和 Sitara 系列 芯片 在 电源 管理 部 分 都 有 模块 PRCM (DM 36X 等 老 的 DaVinci Be 
有 PROM 模块 ) ， 这 个 PRCM 实际 就 是 相似 度 的 表现 之 一 。 另 外 芯片 内 的 某 些 接口 模块 也 
是 相同 的 。 这 些 相似 度 使 得 将 新 一 代 DaVinci 芯片 代码 放 人 mach - omap2 目录 下 管理 更 合 
适 。 新 一 代 DaVinci 芯片 的 代码 也 一 并 在 OMAP3 的 代码 分 支 下 管理 ， 开 自己 维护 的 代码 
分 支 如 下 : 

http ://arago — project. org/git/projects/linux — omap3. git 

Sitara 系列 芯片 的 代码 也 是 在 mach - omap2 Axe F, [HZ&f4 V IB PEE RA PS, TI 
自己 维护 的 Sitara 代码 分 支 如 下 : 

http ://arago — project. org/ git/ projects/ linux — am33x. git 

了 解 软件 系统 一 个 好 的 方式 是 从 Makefile 入 手 进 行 分 析 。 下 面 从 linux - omap3 分 支 的 
mach - omap2 目录 下 的 Makefile 入 手 ， 了 解 OMAP 和 DaVinci 芯片 内 核 特 殊 代 码 的 结构 。 其 
中 OMAP 相关 的 内 容 笔者 会 保留 和 DM 3730 相关 的 部 分 (DM 3730 属于 OMAP3 系列 芯片 ) , 
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去 除 OMAP2 和 OMAP4 相关 的 内 容 。 
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# arch/arm/mach - omap2/ Makefile 
# Makefile for the linux kernel. 


# 适 合 所 有 芯片 相关 的 代码 ,其 中 包括 芯片 一 ,0 地 址 操作 ,系统 控制 模块 相关 操作 ,平台 设备 相关 
# 操 作 ,gp timer 相关 操作 , 引 脚 复 用 相关 操作 等 代码 。 这 些 代 码 是 使 用 该 目录 所 有 芯片 共用 的 


# Common support 



































obj — y :=id. o io. o control. o mux. o devices. o serial. o gpmc. o timer — gp. o pm. o \ 
common. o gpio. o dma. o wd. timer. o elm. o 
#0MAP3 中 断 控制 器 和 内 存 控制 器 代码 


omap — 2-3- common =irq. o sdre. o 














#hwmod 是 抽象 出 来 的 管理 实体 ,是 硬件 接口 模块 的 抽象 实体 。 通 过 该 抽象 将 模块 资源 数据 和 操 
# 作 分 离 ,降低 耦合 度 并 减少 元 余 代 码 


hwmod — common =omap_hwmod. o \ 























omap_hwmod_common_data. o 























# 通 用 的 时 钟 管理 代码 
clock — common = clock. o clock. common. data. o \ 


clkt, dpll. o clkt_clksel. o 









































# 根 据 具 体 的 芯片 系列 加 载 合适 的 通用 模块 
obj - $ (CONFIG_ARCH_OMAP3) += $ (omap -2-3-common) $ (hwmod - common) 
obj - $ (CONFIG_ARCH_TI81XX) += $ (omap -2-3-common) $ (hwmod - common) 








#McBSP 设备 底层 操作 代码 
obj - $ (CONFIG_OMAP_MCBSP) += mcbsp. o 
































HAA EE FEL IE EK HO E, EEG S Hr , BARAR D B CS FS Fr JETT BOE 
obj - $ (CONFIG. TWLA030. CORE) +=omap_twl. o 
obj - $ ( CONFIG. REGULATOR, TPS65023 ) += pmic_tps65023. o 


























#OMAP3 需要 在 片 内 RAM 中 放 和 人 在 特殊 情况 下 使 用 的 代码 。 由 于 这 些 代 码 包括 的 操作 会 使 外 部 
#DDR memory 的 状态 发 生变 化 ,只 有 存放 在 片 内 RAM 才能 保证 稳定 
# Functions loaded to SRAM 























obj - $ ( CONFIG. ARCH, OMAP3) += sram34xx. o 
# 编 译 的 配置 参数 





AFLAGS_sram34xx. o := — Wa, - march = armv7 - a 
# 与 具体 芯片 相关 的 引 脚 复 用 的 代码 

# Pin multiplexing 

obj - $ (CONFIG_ARCH_OMAP3 ) += mux34xx. o 


obj - $ (CONFIG_ARCH_TI81XX) 


#DDR 控制 器 相关 的 代码 
# SMS/SDRC 
obj - $ (CONFIG_ARCH_OM 





AP2) 


+= mux81xx. o mux814x. o 


+= sdre2xxx. o 





# obj - $ ( CONFIG ARCH. OMAP3) += sdre3xxx. o 


#DVFS 的 各 个 操作 点 的 参数 
# OPP table initialization 

ifeq ( $ (CONFIG_PM_OPP) 
obj - y 

obj - $ ( CONFIG ARCH. OM 


22] 


AP3) 


obj - $ ( CONFIG ARCH TI814X) 


endif 

# 与 忆 片 相关 的 实现 Linux 电 
# 代 码 

# Power Management 

ifeq ( $ (CONFIG_PM) ,y) 
obj - $ ( CONFIG ARCH. OM 





pany 


源 管 到 


+= opp. 0 


+= opp3xxx_data. o 





+= opp814x_data. o 








AP3) 


obj - $ (CONFIG_ARCH_TI81XX) 








功能 的 代码 ,其 中 包括 实现 待机 ,运行 时 idle 和 AVS 相关 的 





+= pm34xx. o sleep34xx. o sleep3517. o voltage. o\ 
cpuidle34xx. o pm. bus. o 


+= voltage. o pm. bus. o pm81xx. o sleep814x. o 





obj - $ ( CONFIG. PM. DEBUG) += pm - debug. o 

obj - $ ( CONFIG. OMAP SMARTREFLEX ) -*-sr device. o smartreflex. o 
obj - $ ( CONFIG. OMAP SMARTREFLEX CLASS3) += smartreflex — class3. o 

obj - $ (CONFIG_TI816X_SMARTREFLEX ) += smartreflex — ti816x. o 


# 编 译 参数 

AFLAGS_sleep34xx. o 
AFLACGS sleep3517. o 
AFLACGS sleep814x. o 

















# 用 于 电源 管理 的 debug 

















:= — Wa, - march = armv7 一 a 


= — Wa, — march = armv7 - a 


= — Wa, — march =armv7 - a 


ifeq ( $ (CONFIG, PM. VERBOSE) ,y) 


CFLAGS pm bus. o 
endif 


endif 


# 与 芯片 相关 的 PRCM 数据 和 代码 


# PRCM 


obj - $ (CONFIG_ARCH_OMAP3) 
obj = $ (CONFIG_ARCH_TI81XX) 


+= -DDEBUG 


+= prem. o cm2xxx_3xxx. o prm2xxx_3xxx. o 





+= prem. o cm2xxx_3xxx. o prm2xxx_3xxx. o | 


cm8 | xx. o 
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# 电 源 域 的 管理 框架 
# OMAP powerdomain framework 





mm 








powerdomain — common 


+= powerdomain. o powerdomain — common. o 


# 与 芯片 相关 的 电源 域 代码 ,主要 是 芯片 相关 的 数据 和 特殊 操作 接口 


obj - $ (CONFIG_ARCH_OMAP3) 


obj - $ (CONFIG_ARCH_TI81XX) 


# 时 钟 域 管理 框架 
# PRCM clockdomain control 
obj - $ (CONFIG_ARCH_OMAP3) 





obj - $ ( CONFIG ARCH. TI81XX) 





# 时 钟 框架 的 代码 ,主要 是 各 种 时 钟 的 操作 实现 








# Clock framework 
obj - $ (CONFIG_ARCH_OMAP3 ) 


obj - $ (CONFIG ARCH. TI81XX) 
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# hwmod data 
obj - $ (CONFIG_ARCH_OMAP3 ) 
obj - $ (CONFIG_ARCH_TI81 XX) 





# 某 些 芯片 包含 为 外 部 IO 模块 提供 的 MMU( 比如 DM 3730 4 

















# 实 现在 这 里 
obj - $ (CONFIG_OMAP_IOMMU) 


iommu — $ (CONFIG_OMAP_IOMMU) 
obj - y 

s C 控制 器 的 底层 操作 接口 

i2c — omap — $ (CONFIG_I2C_OMAP) 
obj - y 








+= $ ( powerdomain - common) V 
powerdomain2xxx 3xxx. o V 
powerdomains3xxx, data. o \ 
powerdomains2xxx 3xxx, data. o 
+= $ (powerdomain ~ common) V 
powerdomain2xxx 3xxx. o V 
powerdomains3xxx, data. o \ 


powerdomains2xxx, 3xxx, data. o 


+=clockdomain. o V 
clockdomains2xxx. 3xxx. data. o 
+=clockdomain. o V 


clockdomains2xxx 3xxx. data. o 





+= $ (clock ~ common) clock3xxx. o \ 
clock34xx. o clkt34xx_dpll3m2. o V 
clock3517. o clock36xx. o \ 

dpll3xxx. o clock3xxx, data. o 

+= $ (clock - common) clock816x, data. o V 
clock814x data. o clock81xx. o ti81xx_vpss. o V 
fapll ti816x. o adpll_ti814x. o 





+= omap hwmod, 3xxx. data. o 





+= omap hwmod, 81xx. data. o 





+= iommu2. o 


:= omap — iommu. o 


+= $(iommu-m) $ (iommu - y) 


:三 i2c. 0 


+= $(i2e-omap- m) $ (i2c — omap —y) 


PHY Camera 接口 ) ,相关 的 操作 接口 























#OMAP3 系列 芯片 和 DSP 通信 的 接口 
ifneq ( $ (CONFIG_TIDSPBRIDGE) , ) 


obj - y += dsp. o 

endif 

#PCle 底层 操作 接口 

obj - $ (CONFIG_PCI) += pcie — ti81 xx. o 


ifeq ( $ (CONFIG_PCI_DEBUG) ,y) 
CFLAGS pcie — ti81xx. o += - DDEBUG 
endif 





# 板 级 特殊 代码 ,只 保留 DM 3730 开发 板 级 和 DM 81XX 系列 的 文件 

# Specific board support 

#board — generic 此 文件 是 通过 Device Tree 来 定义 板 级 特殊 数据 ,后 续 文 件 都 是 文件 中 明确 定义 

# 板 级 数据 

obj - $ ( CONFIG. MACH. OMAP GENERIC ) += board — generic. o 

obj - $ ( CONFIG. MACH. OMAP3EVM ) += board - omap3evm. o V 
hsmme. o V 
board — flash. o 

obj - $ ( CONFIG. MACH TI8148EVM ) += board - ti8148evm. o V 
hsmme. o V 
board — flash. o 

obj - $ ( CONFIG. MACH, DM385EVM ) += board — dm385evm. o V 
hsmme. o V 
board — flash. o 

obj - $ (CONFIG_MACH_TI811XEVM) += board — ti811xevm. o \ 
hsmme. o V 
board — flash. o 

obj - $ (CONFIG MACH. TI8168EVM ) += board - ti8168evm. o V 
hsmme. o V 
board — flash. o 

# 有 具体 接口 模块 设备 ,根据 自行 设计 板子 中 实际 使 用 的 设备 进行 配置 






























































usbfs - $ (CONFIG_ARCH_OMAP_OTG) := usb — fs. o 

obj — y += $ (usbfs -m) $ (usbfs — y) 

obj - y += usb — musb. o 

obj - y += usb - ehci. o 

onenand — $ ( CONFIG. MTD ONENAND. OMAP2) := gpmc — onenand. o 

obj - y += $ (onenand- m) $ (onenand - y) 
nand — $ (CONFIG. MTD. NAND. OMAP2) := gpmc — nand. o 

obj - y += $(nand- m) $ (nand -y) 
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# 上 有 具体 的 以 太 网 设备 接口 ,主要 是 OMAP 系列 处 理 器 使 用 ,由 于 OMAP 系列 处 理 器 中 不 包含 以 太 
# 网 控制 器 ,需要 通过 同步 硬件 接口 连接 外 部 的 以 太 网 控制 器 实现 以 太 网 功能 。 以 下 SMC91X 
# 和 SMSCO11X 是 OMAP 开发 板 上 使 用 过 的 以 太 网 控制 器 
























































smc91x — $ (CONFIG_SMC91X ) := gpme —smc91x. o 

obj - y += $(smc91x-—m) $ (smc91x - y) 
smsc911x — $ (CONFIG_SMSC911X) := gpme —smsc911x. o 

obj - y += $(smscOllx - m). $ (smscOllx — y) 


ifeq ( $ (CONFIG MACH. OMAP3EVM) , y) 





evm - camera — $ (CONFIG. VIDEO. OMAP3) := board — omap3evm — camera. o 
obj - y += $ (evm -camera - m) $ (evm — camera - y) 
endif 





了 解 mach - omap2 之 后 就 该 来 认识 plat - omap 目录 了 。 该 目录 主要 为 各 种 设备 驱动 提 
供 统一 的 接口 操作 ， 以 此 屏蔽 世 片 的 特殊 操作 ， 比 如 GPIO、DMA 、 时 钟 等 。 早 期 的 Linux 
内 核 中 并 没有 提供 这 些 设备 的 统一 操作 接口 ， 随 着 Linux 内 核 的 发 展 ， 逐 渐 增 加 了 这 些 设备 
的 统一 接口 ， 该 目录 存在 的 意义 就 必然 减 小 。 

至 此 可 以 明确 从 芯片 的 复杂 度 来 看 ，DM 3730 是 最 复杂 的 ， 相 对 于 其 他 芯片 来 说 其 技术 
含量 也 是 最 高 的 。 可 以 说 如 果 能 深刻 理解 DM 3730 及 其 Linux 内 核 代 码 ， 那 么 除了 个 别 DM 
3730 没有 包含 的 设备 接口 驱动 外 ， 再 看 其 他 芯片 的 代码 都 是 游 耻 有余 的 。 因 此 笔者 会 以 TI 
官方 发 布 的 Android 开发 包 中 DM 3730 的 内 核 代码 为 主 ， 进 行 Linux 内 核 及 设备 驱动 的 剖析 ， 
但 是 为 了 避免 局 限 性 ， 必 要 时 会 扩展 到 其 他 芯片 ， 以 及 新 版 本 的 内 核 进 行 说 明 。 






































2.5 小 结 


本 章 着 重 介绍 了 的 各 种 人 散 入 式 处 理 天 及 其 特点 。 并 从 电源 管理 出 发 深入 分 析 了 电源 
管理 技术 以 及 各 个 系列 芯片 的 实现 细节 ， 从 中 可 以 体会 到 芯片 设计 本 身 是 软件 硬件 、 性 价 
比 、 能 耗 比 等 因素 综合 考虑 的 结 

另外 本 章 对 芯片 相关 的 内 核 代 码 的 结构 进行 了 分 析 。 从 结构 分 析 中 可 以 看 出 ， 硬 件 实现 
的 概念 或 模块 在 软件 中 基本 都 有 对 应 的 实体 。 软 件 实现 中 为 了 降低 耦合 度 减少 元 余 代码 会 进 
行进 一 步 的 抽象 ， 形 成 统一 的 接口 和 框架 。 从 这 点 出 发 就 能 更 好 地 理解 处 理 咒 的 内 核 代码 。 
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453% Linux 内核 框架 探究 


谈 到 Linux， 首 先 想 到 的 是 类 似 Ubuntu 这 样 复杂 的 系统 。 说 到 Linux 系统 复杂 ， 确 实 如 
此 ， 光 是 受 欢迎 的 桌面 发 行 版 本 就 超过 十 种 之 多 。 要 是 算 上 各 种 各 样 的 嵌入 式 应 用 的 Linux 
系统 ,估计 要 超过 百 种 之 多 。 面 对 如 此 复杂 的 系统 ， 没 有 必要 害怕 ， 数 量 上 虽然 多 ,但 是 整 
个 系统 的 框架 却 是 相同 的 。Linux 系统 框架 如 图 3-1 所 示 。 






























inversions user system data net 
presentation desktops packaging file management net clients 
high level Wxfce Gnome EIKDE kpackage emer #Thunar Konqueror @Firefox 
general purpose _ office une PARSE ent “Nautilus Krusader AKMail Thunderbird 
user programs G@OpenOffice 国 Koffice [H K3b gnome-commander — & Pidgin Kopete 
/usr/bin /usr/lib & Evolution LaTeX rpm urpmi dpkg tar bzip2 Ark gzip Mutt mail 
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Me MPlayer marok Emacs Anjuta {vim diff Meld kdiff3 grep Wireshark tcpdump 
application ZYFFmpeg =GStreamer sed nano kate gedit 
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rograms AVLC Xine Mul - textutils: wget netcat curl 
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services metacity klogd cpid syslogd Perl pHp data & net sshd Apac 
AMP ; T 
servers | gdm XX.org kdm 91 awk Python Mule Postfix inetd 
nterpreters 5 * B 
infrastructure UGTK+ Ho | SE DBs udev DBMS portmap named 
= PostgreSQL F FS 
/usr/sbin /usr/lib Ipd cups p. SQLite reat samba NetworkManager 
control user access storage config SCS! network adm 
su nemo : : ^ 
administration Ees hl iwconnig ip 
| man chown adduser ps jobs s mkdir iptables netstat 
pasic access bash chmod echo chkconfig route ifconfig 
Isbin /bin " , 


host socklist 







console | processes 
itrd /lib/module 
HID 


3-1 Linux 系统 框架 





图 3-1 中 可 以 看 到 与 上 层 的 复杂 多 样 相 比 ， 基 础 层 (foundation) 的 核心 是 简单 唯一 的 
Linux 内 核 (Linux Kernel 4) 。 也 正 是 因为 Linux 内 核 的 唯一 性 ， 各 个 不 同 发 布 版 本 拥有 相同 
的 框架 。Linux 内 核 是 在 整个 Linux 系统 的 最 底层 ， 它 负责 管理 硬件 ， 运 行 用 户 程序 ， 并 保 
持 系统 整体 的 安全 性 和 完整 性 。 虽 然 Linux 内 核 在 Linux 系统 中 是 很 小 的 一 部 分 ， 但 它 是 
Linux 系统 的 核心 ， 并 决定 了 整个 系统 的 性 能 和 效率 ， 在 整个 Linux 系统 中 起 着 独一无二 的 
作用 。 可 以 说 是 Linux 系统 的 根 和 灵魂 。 

图 3-1 中 看 到 Linux 内 核 还 有 另 一 层面 的 含义 。 从 层次 的 角度 考虑 ， 底 层 的 模块 都 是 提 
供 服 务 的 ， 服 务 要 能 够 满足 应 用 的 各 种 需求 。 应 用 需求 的 变化 必然 对 底层 提出 更 多 的 要 求 ， 
因此 底层 的 服务 不 能 固定 不 变 ， 也 是 要 发 展 的 。 这 对 于 Linux 内 核 同 样 适 用 。 当 然 Linux 内 
核 毕 竞 是 在 硬件 之 上 的 层次 ， 所 以 应 用 需求 的 变化 发 展 不 能 完全 依赖 于 Linux 内 核 解 决 ， 一 
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部 分 的 实现 还 是 要 硬件 支持 才 行 〈 比如 虚拟 化 技术 ) 。 

可 见 整 个 系统 的 发 展 是 一 个 综合 的 结果 ， 对 其 中 一 部 分 的 研究 也 应 该 综合 考虑 。 所 以 对 
Linux 内 核 的 剖析 、 学 习 和 研究 也 不 能 独立 于 系统 进行 ， 而 是 要 综合 考虑 应 用 、 内 核 和 硬件 
等 各 方面 的 信息 和 内 容 。 这 样 才 能 更 全 面 、 深 刻 地 理解 Linux 内 核 。 





3.1 内 核 框架 概述 





关于 Linux 系统 框架 在 图 3-1 中 已 经 比较 详尽 的 展示 ， 如 果 将 其 中 的 层次 关系 进行 简化 
就 得 到 图 3-2。 






































从 图 3-2 中 可 以 理解 Linux 内 核 就 是 将 硬件 的 功能 抽象 en tee eerie 

出 来 ， 为 用 户 的 应 用 程序 提供 各 种 系统 服务 。 这 些 系统 服务 

在 内 核 中 必然 会 有 体现 ， 系 统 服务 本 身 就 是 应 用 层 需要 的 各 | 

种 各 样 的 功能 (function)。 关 于 功能 ， 图 3-1 中 也 有 一 些 体 OVID 
现 ， 如 用 户 管理 、 系 统管 理 、 数 据 管理 和 各 种 网 络 功能 。 这 

几 部 分 完全 是 从 用 户 使 用 的 角度 考虑 的 ， 而 Linux 内 核 的 一 | 

个 重要 功能 就 是 管理 硬件 ， 在 其 功能 中 必然 要 体现 硬件 的 各 Linux Kemel 
个 功能 。 所 不 同 的 是 Linux 内 核 不 是 将 硬件 的 各 个 功能 一 成 

不 变 的 体现 给 应 用 层 ， 而 是 需要 遵循 应 用 层 的 功能 需求 进行 | 
逻辑 的 转换 。 从 这 个 角度 理解 Linux 内 核 ， 其 主要 功能 就 是 Hardware 

















管理 硬件 、 将 硬件 的 资源 进行 合理 的 抽象 并 开放 给 应 用 层 ， 
应 用 层 则 无 权 直接 访问 硬件 ， 必 须 通 过 操作 系统 来 完成 相应 ”图 3-2 Linux 系统 简化 层次 图 
的 功能 。 这 种 权限 划分 和 转换 是 以 处 理 器 权限 分 级 为 基础 来 
实现 的 〈 应 用 层 处 于 普通 权限 ， 而 操作 系统 则 有 特权 ) 。 当 然 Linux 内 核 是 需要 支持 多 用 户 
的 ， 考 虑 用 户 的 因素 ， 就 需要 在 各 种 物理 资源 和 抽象 资源 中 加 上 与 用 户 相关 的 属性 ( 比如 
资源 的 拥有 者 owner， 权 限 等 )。 与 用 户 相 关 的 属性 是 与 Linux 内 核 中 整体 安全 性 相关 的 ， 这 
部 分 功能 通常 和 硬件 具体 功能 关系 不 大 ， 而 是 附加 在 逻辑 功能 之 上 的 属性 。 本 书 是 以 嵌入 式 
系统 为 基础 进行 说 明 ， 所 以 将 重点 放 在 硬件 设备 的 具体 功能 以 及 Linux 内 核 在 硬件 之 上 的 具 
体 实 现 方面 。 安 全 相关 的 逻辑 属性 及 功能 不 会 进行 说 明 。 

Linux 内 核 的 整体 框架 如 图 3-3 所 示 。 图 3-3 清晰 地 展现 了 Linux 内 核 的 实现 层次 ， 以 
及 应 用 层 功 能 和 硬件 功能 的 对 应 关系 。 通 过 该 图 ， 可 以 了 解 Linux 内 核 是 如 何 通过 各 个 层次 
的 抽象 ， 将 硬件 功能 转换 成 应 用 层 实际 需要 的 功能 。 


3.1.1 Linux 内 核 的 层次 分 析 


通过 分 析 图 3-3， 可 以 了 解 Linux 内 核 是 如 何 一 层 一 层 的 将 设备 功能 转换 为 用 户 功 能 
的 。 按 照 这 种 层次 的 角度 可 以 将 Linux 内 核 分 为 五 层 ， 分 别 如 下 : 

(D user space interfacea; 该 层 是 Linux 内 核 直接 面向 用 户 层 的 接口 ， 实 现 用 户 层 需要 的 
各 种 功能 。 该 层 在 各 个 Linux 内 核 版 本 中 尽量 保持 一 致 。 该 层 可 以 屏蔽 各 个 版 本 内 核 在 功能 
实现 的 细节 差别 ， 从 而 为 应 用 层 提 供 统一 接口 ， 降 低 应 用 层 和 内 核 之 间 的 耦合 度 。 

(2) virtual subsystems: 该 层 为 虚拟 子 系统 层 。 所 谓 虚 拟 实际 是 一 种 高 级 抽象 ， 是 将 下 层 
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图 3-3 Linux 内 核 整体 框 
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CEE) 不 同 的 具体 实现 中 体现 的 数据 和 操作 再 做 进一步 抽象 ， 单 独 形成 的 一 层 。 该 层 主 
要 目的 就 是 为 了 形成 实现 无 关 的 一 层 ， 使 得 整个 系统 不 依赖 于 具体 的 逻辑 实现 。 使 上 层 系统 
从 复杂 多 变 的 实现 中 解放 出 来 。 不 仅 提高 了 系统 实现 的 灵活 度 ， 也 降低 系统 耦合 度 。 

(3) bridges: 桥梁 层 。Linux 内 核 中 各 个 功能 模块 之 间 不 是 独立 的 ， 会 有 交叉 功能 的 需 
要 ， 比 如 文件 需要 映射 到 虚拟 地 址 空间 ， 网 络 文件 系统 的 实现 ， 这 些 功能 都 是 需要 跨越 不 同 
功能 的 实体 。 当 跨越 不 同 功能 实体 时 ， 需 要 在 二 者 之 间 建 立 关联 ， 也 就 是 桥梁 。 另 外 某 些 功 
能 本 身 就 需要 有 很 多 的 实体 ， 比 如 在 处 理 器 之 上 的 执行 实体 进程 (process) ， 而 功能 内 部 的 
多 个 实体 之 间 也 需要 相互 沟通 ， 这 样 就 需要 桥梁 层 的 实现 来 解决 这 个 问题 。 总 之 当 需 要 沟通 
或 者 转换 时 就 需要 在 bridges 层 实现 。 

@ logical: 该 层 负责 功能 的 四 辑 实现 。 某 一 个 具体 的 功能 可 以 有 很 多 种 实现 ， 而 这 些 具 
体 的 实现 都 是 在 logical 层 。 比 如 Linux 的 文件 系统 有 ext2 和 ext3 不 同 的 实现 逻辑 ， 而 ext2 
和 ext3 都 是 在 logical 层 中 。 可 以 说 该 层 是 Linux 内 核 中 最 多 样 的 一 层 ， 但 是 这 些 多 样 实现 通 
过 设计 良好 的 接口 去 封装 ， 使 功能 之 间 并 没有 耦合 ， 因 此 没有 增加 系统 的 复杂 度 。 

©) hardware interfaces; 该 层 是 Linux 内 核 的 最 底层 ， 其 直接 面向 具体 的 硬件 设备 ， 是 将 
硬件 的 具体 功能 提供 给 Linux 内 核 的 接口 层 。 该 接口 层 将 设备 的 功能 分 类 ， 并 抽象 出 统一 接 
口 给 Linux 内 核 使 用 。Linux 内 核 通 过 统一 的 接口 操作 设备 ， 这 样 就 屏蔽 了 各 个 设备 的 差异 ， 
从 而 降低 了 和 硬件 的 耦合 关系 。 

Linux 内 核 各 层 体现 不 同 程度 的 抽象 ， 越 往 上 层 抽象 程度 越 高 ， 覆 盖 面 越 大 ， 也 越 接近 
于 应 用 的 需求 ; 越 往 底 层 其 体现 的 特殊 性 就 越 多 ， 获 盖 面 越 小 ， 越 接近 于 具体 的 设备 。 有 了 
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这 些 层次 的 概念 ， 对 了 解 Linux 内 核 是 很 有 帮助 的 ， 在 具体 的 实现 中 需要 明确 模块 是 在 哪 一 
层 ， 具 体 管理 的 抽象 实体 是 什么 ,掌握 了 这 些 ， 基 本 的 框架 就 能 理解 了 。 

现在 可 以 通过 具体 功能 的 例子 ， 看 看 Linux 内 核 是 如 何 通过 各 层 的 抽象 ， 使 用 设备 实现 
用 户 功 能 的 。 

1. 程序 执行 (processing) 功能 

processing 功能 对 应 的 硬件 实体 是 CPU, CPU 是 执行 指令 的 单元 ， 它 可 以 接收 外 部 事件 
(通过 中 断 Interrupt) 。 指 令 执 行 需要 操作 数 ， 相 同 操作 指令 结果 的 多 样 性 通过 操作 数 的 变化 
来 实现 。 操 作 数 可 以 从 memory 中 读 取 ， 这 就 可 以 通过 使 用 相同 的 指令 而 从 不 同 的 memory 
地 址 取 操 作 数 ， 实 现 操 作 结果 的 变化 ， 从 而 增加 了 系统 的 灵活 性 。 另 外 执行 逻辑 的 变化 可 以 
通过 跳 转 指令 完成 ， 同 样 通过 从 memory 读 取 指令 地 址 ， 可 以 实现 多 变 的 执行 逻辑 。 这 样 不 
同 的 操作 数 和 跳 转 地 址 组 合成 一 块 memory， 这 些 不 同 的 memory (PER) 就 可 以 产生 多 变 
的 系统 执行 流程 和 结果 。CPU 通过 栈 指针 寄存 器 可 以 指向 不 同 的 memory 的 位 置 。 为 了 减少 
寄存 器 ， 软 件 对 该 寄存 器 操作 流程 进行 特殊 规定 ， 这 样 通过 硬件 和 软件 结合 ， 使 得 CPU 可 
以 在 不 同 的 指令 执行 流程 和 操作 数 之 间 切 换 。 从 CPU 的 角度 来 看 ， 它 就 是 按照 指令 的 要 求 ， 
在 不 同 的 执行 流程 中 进行 切换 并 执行 指令 ; 从 操作 系统 的 角度 考虑 ， 这 些 不 同 的 软件 执行 流 
程 就 是 线程 (thread), Linux 内 核 为 了 简化 实现 ， 将 共享 资源 的 进程 作为 线程 。 图 3-4 展示 
了 Linux 内 核 中 进程 间 (不 同 的 执行 流程 ) 的 切换 ， 就 是 通过 内 核 栈 的 改变 来 实现 的 ， 有 具体 
是 通过 switch. to 函数 实现 。 









































ie | Before awitch to 
Kernel mode next - B next = C next = 4 Pran 
stack prev=A prw=B prew=C prev - C. } After switch. to returns 





Process 


Å= switch to(AB) C= switch to(b A) 
B-switch to(B.C) 


图 3-4 Linux 进程 切换 实现 逻辑 


有 些 执行 流程 的 切换 是 由 CPU 自动 完成 的 ， 比 如 中 断 、 异 常 ， 这 些 都 是 系统 为 了 满足 
外 部 事件 ， 以 及 安全 性 、 容 错 性 的 需求 。 有 了 中 断 之 后 系统 就 能 对 外 部 事件 进行 管理 。 由 于 
不 同 的 CPU 中 断 处 理 存 在 差异 ， 这 就 需要 软件 上 抽象 出 中 断 管 理 的 接口 。 图 3-3 中 硬件 接 
口 层 中 的 interrupt 核心 就 是 实现 该 功能 的 ， 具 体 的 CPU 只 要 实现 相应 的 接口 就 可 以 在 Linux 
内 核 中 实现 对 中 断 的 管理 。 

考虑 到 外 部 事件 需要 对 执行 流程 进行 转换 ， 另 外 不 同 的 应 用 执行 流程 之 间 需 要 切换 ， 这 
就 要 在 Linux 内 核 的 逻辑 层 抽 象 出 调度 需 这 一 逻辑 功能 。 该 功能 负责 在 不 同 线程 之 间 选 择 合 
适 的 线程 来 让 CPU 执行 〈 即 切换 到 相应 的 执行 流程 中 ) ， 以 完成 对 应 的 任务 。 注 意 调度 器 实 
际 是 个 选择 器 ， 其 按照 一 定 的 算法 选择 合适 的 任务 ， 具 体 的 切换 执行 在 Linux 内 核 中 是 由 
switch, to 函数 实现 的 。Linux 作为 多 用 户 系 统 ， 调 度 器 的 算法 和 性 能 十 分 重要 ， 因 为 其 影响 
到 所 有 用 户 的 感受 。 
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Linux 内 核 将 它们 作为 一 个 整体 进行 抽象 ， 这 就 形成 了 进程 的 概念 ， 这 在 Linux 内 核 中 就 是 
虚拟 子 系统 层 中 的 task。 同 样 在 应 用 接口 层 也 需要 相应 的 接口 对 task 进行 操作 ， 比 如 创建 、 
设置 不 同 的 执行 指令 等 。 

大 型 的 任务 需要 分 多 个 线程 或 者 进程 来 完成 ， 这 样 可 以 降低 系统 复杂 度 ， 这 就 提出 了 多 
个 线程 或 进程 之 间 沟 通 并 同步 的 需求 ， 这 部 分 就 是 bridges 层 的 功能 。 

2. 内 存 管理 (memory) 功能 

内 存 管理 主要 是 对 RAM 的 管理 ， 是 Linux 内 核 中 很 大 的 一 部 分 功能 。 应 用 层 的 程序 需 
要 任何 时 刻 都 能 以 应 用 程序 自己 设 定 的 地 址 访问 数据 ， 并 且 应 用 程序 应 该 只 能 知道 自己 的 地 
址 。 这 样 从 应 用 程序 自身 地 址 的 角度 考虑 ， 不 同 的 应 用 程序 必然 会 使 用 相同 的 地 址 做 不 同 的 
事情 。 而 物理 内 存 作为 唯一 资源 就 无 法 实现 同一 地 址 存放 不 同 的 内 容 。 这 就 产生 了 了 矛盾， 也 
就 需要 应 用 程序 的 地 址 和 物理 内 存 的 地 址 不 能 是 相同 的 概念 ， 这 之 间 的 鸿沟 需要 通过 一 种 转 
换 进 行 解决 ， 这 样 就 产生 了 MMU 。 由 于 应 用 程序 的 地 址 空间 不 直接 对 应 于 物理 内 存 的 地 址 ， 
所 以 在 Linux 内 核 中 形成 虚拟 地 址 (virtual address) 。Linux 内 核 需 要 对 所 有 应 用 层 任务 的 虚 
拟 地 址 空间 进行 管理 ， 这 部 分 就 形成 了 virtual 子 系统 层 中 的 virtual memory。 当 然 对 虚拟 地 
址 空间 的 管理 不 只 是 管理 地 址 ， 同 时 还 要 管理 相应 空间 中 存放 数据 及 数据 的 属性 ， 不 同性 质 
的 数据 在 地 址 空间 中 不 应 该 有 交 义 和 重 羡 。Linux 虚拟 地 址 组 织 结构 如 图 3-5 所 示 。 注 意 虚 
拟 地 址 空间 是 和 task 相关 联 的， 并 且 其 中 的 数据 是 有 分 别 的 ， 每 块 虚拟 空间 中 存放 的 数据 
都 有 不 同 的 属性 和 操作 方式 。 
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图 3-5$ Linux 虚拟 地 址 组 织 结构 


物理 内 存 是 一 个 被 动 器 件 ， 只 是 接受 地 址 和 数据 进行 读 写 的 操作 ， 有 具体 数据 的 属性 并 不 
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关心 。 物 理 内 存 究 竟 如 何 管理 是 个 需要 仔细 考虑 的 问题 。 管 理 总 是 要 考虑 粒度 的 ， 如 果 过 大 
就 会 有 粒度 内 部 浪费 的 问题 ， 如 果 过 小 就 会 消耗 更 多 的 资源 来 进行 管理 。 权 衡 下 来 ， 硬 件 的 
体系 结构 通常 将 最 小 的 内 存 管理 单元 定义 成 页 (page) ， 把 页 大 小 〈 即 粒度 ) 的 设置 留 给 系 
统 软件 完成 。 可 以 由 系统 软件 根据 管理 的 物理 地 址 空间 以 及 内 存 的 大 小 来 进行 设置 。ARM 
就 可 以 设置 4KB 或 者 64 KB 不 同 的 页 大 小 。 

当然 仅 是 页 管理 不 能 满足 系统 所 有 模块 对 内 存 使 用 的 需求 ， 这 就 需要 在 页 的 管理 之 上 将 
数据 进行 结构 的 和 细 粒 度 的 管理 ， 这 在 Linux LEGE ASHIZ TUE T. slab 内 存 管理 ， 为 内 核 其 
他 模块 提供 管理 内 存 的 结构 。slab 分 为 kmem_cache 和 kmalloc 两 种 形式 ,kmem_cache 提供 
结构 化 的 内 存 管理 ，kmalloc 则 提供 细 粒 度 的 内 存 管理 。 

虚拟 地 址 到 物理 地 址 的 变换 ， 硬 件 上 由 MMU 来 实现 ， 其 中 也 会 涉及 管理 页 的 大 小 ， 
ARM 下 MMU 的 实现 逻辑 如 图 3-6 所 示 。 其 中 各 级 页 表 也 都 是 存放 在 内 存 中 ， 一 级 页 表 的 
地 址 存放 在 系统 寄存 器 中 ， 对 进程 的 切换 时 同样 需要 切换 页 表 。 


W On ARM, without LPAE, the MMU use an asymmetric 2-level scheme: 


31 30 28 28 27 26 25 24 23 22 21 20 18 18 17 16 15 14 13 12 11109 80 7 6 5 4 3 2 1 0 











MM 








W Note: Page 22 
O For 64KB pages, 16 identical, properly aligned PTEs refer to the same page 


3-6 ARM MMU 实现 逻辑 


需要 注意 的 是 对 CPU 来 说 ， 只 要 有 页 表 MMU ， 就 能 通过 虚拟 地 址 完成 实际 物理 地 址 的 
具体 操作 ，CPU 本 身 并 不 需要 对 虚拟 空间 进行 管理 。 虚 拟 空间 管理 则 是 完全 针对 虚拟 地 址 
进行 的 。 由 于 虚拟 地 址 和 task 是 关联 的 ， 所 以 实际 上 ， 虚 拟 空间 管理 在 Linux 内 核 中 就 是 对 
所 有 用 户 进程 虚拟 空间 的 管理 。 

3. 存储 (storage) 管理 

存储 管理 针对 的 硬件 设备 是 外 部 磁盘 ， 如 IDE, SATA, SCSI 等 。 随 着 能 人 式 的 发 展 ， 
外 部 存储 设备 又 增加 了 Nand, SD 卡 等 。 这 些 存储 设备 的 特点 是 大 多 硬件 要 求 以 块 为 单位 进 
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行 操作 ， 这 就 已 经 定 下 了 管理 粒度 即 块 。 存储 设 备 的 这 个 特性 自然 的 形成 了 block device 和 
block driver 作为 硬件 接口 层 。 该 硬件 接口 层 只 是 完成 以 块 为 单元 的 数据 操作 。 

数据 在 存储 设备 中 如 何 组 织 分 配 等 更 细致 的 问题 ， 就 需要 逻辑 层 处 理 。 这 部 分 处 理 细 化 
出 各 种 文件 系统 ， 当 然 某 些 数据 库 也 是 在 逻辑 层 实现 的 。 文 件 系统 屏蔽 了 块 设 备 的 细节 ， 而 
且 将 数据 组 织 并 抽象 出 文件 的 概念 。 为 了 更 好 地 组 织 、 管 理 和 查找 文件 ， 可 以 将 多 个 文件 放 
入 一 个 目录 ， 这 又 形成 了 目录 的 概念 。 文 件 系统 管理 的 是 这 些 逻 辑 层 面 的 概念 ， 以 及 对 应 到 
实际 设备 块 的 映射 逻辑 。 具 体 的 块 操 作 完 全 由 设备 接口 层 完成 。 

由 于 逻辑 层 有 各 种 各 样 的 文件 系统 ， 则 需要 在 虚拟 层 再 进行 抽象 ， 屏 蔽 各 种 具体 实现 的 
差异 ， 从 而 形成 虚拟 文件 系统 模块 。 这 样 用 户 接口 层 就 可 以 通过 虚拟 文件 系统 的 统一 接口 对 
不 同 的 文件 系统 进行 操作 。 

又 由 于 外 部 磁盘 读 写 比 较 慢 ， 而 内 存 读 写 速度 要 快 得 多 ， 这 样 在 逻辑 上 做 成 页 缓冲 可 以 提 
高 性 能 。 在 层次 上 页 缓冲 涉及 虚拟 文件 系统 和 页 管理 ， 属 于 交叉 功能 ， 所 以 应 该 在 bridges JZ 
实现 。 

4. 网 络 (networking) 管理 

网 络 管理 最 底层 是 网 络 设备 ， 相 当 于 网 络 协议 分 层 的 物理 层 。 其 他 层 的 网 络 协议 是 在 物 
理 层 之 上 的 ， 同样 的 网 络 设备 上 可 以 传输 不 同 的 上 层 网 络 协议 封装 的 数据 。 所 以 在 层次 上 ， 
物理 层 之 上 的 协议 归 入 逻辑 层 ， 而 物理 层 的 设备 归 入 设备 接口 层 。 

再 向 上 同样 需要 抽象 出 对 协议 族 的 管理 和 对 应 用 层 的 socket 接口 来 简化 用 户 的 操作 。 

5. 系统 (system) 管理 

Linux 内 核 中 有 各 种 各 样 的 系统 。 为 了 提升 系统 在 不 同情 况 下 的 适应 能 力 ， 通 常 各 种 系 
统 都 会 有 一 些 参数 和 状态 信息 提供 给 用 户 或 者 系统 管理 人 员 ， 进 行 查看 、 修 改 、 调 优 。 这 就 
需要 Linux 内 核 设 计 统 一 的 接口 ， 可 以 让 各 个 系统 模块 的 开发 者 来 添加 相应 的 参数 ， 同 样 需 
要 为 应 用 开放 统一 的 操作 接口 和 方式 。 随 着 Linux 的 发 展 ， 最 终 产 生 了 proc 和 sysfs 两 个 大 
的 接口 系统 进行 该 类 操作 。 该 部 分 实现 会 散布 在 各 个 系统 功能 中 ， 本 身 的 层次 概念 可 以 参考 
图 3-3 ， 但 不 是 必需 的 。 

6. 用 户 界 面 (user interface) 管理 

用 户 界 面 直接 关系 到 用 户 体 验 的 部 分 ， 设 备 也 是 最 复杂 多 样 的 。 比 如 键盘 、 鼠 标 、 显 示 
器 、 音 频 设 备 、 摄 像 头 等 各 种 各 样 的 设备 ， 这 些 设 备 没 有 统一 的 数据 格式 和 标准 ， 如 果 一 定 
要 找 这 些 设备 的 共同 点 就 是 数据 有 时 效 性 。 数 据 的 意义 和 时 间 是 关联 的 ， 任 何 数据 会 因为 时 
间 的 改变 而 意义 不 同 ， 用 《信号 与 系统 》 中 的 名 词 就 是 时 变 系 统 。 如 何在 系统 中 抽象 并 管 
理 这 些 设备 是 比较 复杂 的 问题 。Linux 内 核 大 牛 们 用 了 一 个 很 精巧 的 办 法 ， 就 是 首先 使 用 高 
级 别 的 抽象 概念 设备 文件 ， 该 类 设备 都 归结 为 字符 设备 (char device); 其 次 将 操作 也 抽象 
处 理 成 为 统一 接口 ， 而 将 具体 设备 的 属性 完全 留 给 底层 的 设备 驱动 来 进行 管理 。 这 样 应 用 层 
程序 就 可 以 通过 统一 的 字符 设备 (char device) 文件 进行 操作 。 

下 层 的 实现 可 以 针对 设备 的 特点 加 入 更 多 的 细节 进行 管理 ， 这 样 Linux 内 核 中 就 针对 不 
同 设备 的 特点 进行 归 类 ， 形 成 input、audio frame buffer, video 等 各 种 各 样 的 设备 类 型 。 这 
些 设备 类 型 的 具体 实现 一 般 是 归 入 逻辑 层 。 

逻辑 层 之 下 就 是 具体 设备 的 驱动 ， 归 人 设备 接口 层 。 在 罗 辑 层 之 上 ， 可 以 将 与 设备 传输 
的 数据 进行 抽象 或 者 格式 化 ， 形 成 系统 统一 的 规范 ， 比 如 input event 处 理 等 ， 将 这 部 分 作为 
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虚拟 层 。 

这 样 各 个 层次 紧密 结合 ， 既 可 以 适应 广泛 的 设备 ， 又 可 以 对 应 用 提供 统一 操作 接口 。 当 
然 对 具体 类 型 设备 的 操作 要 遵循 相应 类 型 设备 的 操作 规范 。 

注意 在 图 3-3 中 只 有 char device 出 现在 用 户 空间 接口 层 ， 这 并 不 意味 着 块 设备 不 可 以 
直接 对 用 户 应 用 程序 开放 。 只 是 这 种 开放 通常 只 针对 像 fdisk 这 种 格式 化 或 者 文件 系统 相关 
的 工具 。 逻 辑 上 块 设备 更 应 该 是 在 文件 系统 之 下 ， 作 为 数据 存储 的 基础 。 

对 各 个 层 进行 深刻 理解 ， 有 助 于 内 核 以 及 驱动 开发 人 员 更 加 明确 地 理解 系统 各 个 功能 的 
实现 机 制 和 设计 思路 ， 通 过 理解 每 层 的 抽象 概念 可 以 更 好 地 跳出 细节 理解 系统 。 


3.1.2 Linux 内 核 模块 间 关 联 


对 于 复杂 的 软件 系统 ， 在 框架 设计 时 都 会 有 层次 的 概念 。 系 统 框 架 的 层次 设计 有 很 多 好 
处 ， 如 层次 化 设计 使 得 系统 层次 分 明 ， 可 以 提高 重用 性 ， 使 得 系统 耦合 度 低 。Linux 采用 层 
次 化 的 设计 自然 也 有 这 些 优点 。 但 是 ， 软 件 系 统 设 计 ， 不 是 简单 的 纵向 层级 就 能 完全 解决 所 
有 的 问题 ， 软 件 系统 中 通常 都 会 有 横 蜂 多 个 纵向 模块 的 功能 〈 称 作 横 切 功能 ) ， 比 如 日 志 
Sk. Linux 内 核 中 也 不 乏 这 样 的 功能 ， 比 如 sys 文件 系统 等 。 另 外 Linux 框架 也 是 不 断 发 展 
的 ， 为 了 满足 各 种 性 能 的 需求 ， 不 能 为 了 层次 而 层次 ， 而 是 需要 将 整个 系统 打 薄 ， 可 以 看 到 
Linux 内 核 很 多 时 候 会 有 模块 进行 跨 多 层 的 联系 。Linux 内 核 模 块 之 间 详 细 的 关联 如 图 3-7 
所 示 。 
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Al3-7 引 自 http://www. makelinux. net/kernel_map/, 读者 可 以 直接 下 载 了 解 更 详细 的 
内 容 。 看 到 Linux 内 核 复杂 的 关联 ， 可 能 有 些 读者 会 有 您 惯 感 。 但 是 不 要 担心 ， 理 解 这 些 关 
联 的 基础 是 Linux 内 核 的 层次 ,这 在 前 面 已 经 做 了 详细 介绍 ， 后 续 的 章节 还 会 梳理 这 些 关 联 
的 关系 ， 这 里 先 有 个 概念 。 








3.2 需求 探究 





探讨 需求 首先 要 考虑 的 就 是 需求 从 哪里 来 的 问题 。 这 就 涉及 用 户 是 谁 的 问题 。Linux 内 
核 的 用 户 是 谁 呢 ? Linux 内 核 的 用 户 不 是 Linux 桌面 系统 的 使 用 者 ， 主 要 是 两 类 程序 开发 人 
员 ， 一 类 是 应 用 层 的 开发 人 员 ， 另 一 类 是 内 核 及 驱动 的 开发 人 员 。 

这 两 类 开发 人 员 看 Linux 内 核 系统 的 视角 是 不 同 的 ， 应 用 层 开 发 人 员 是 从 外 部 看 Linux 
内 核 ， 更 多 的 是 将 内 核 作为 黑 盒 ; 而 内 核 及 驱动 开发 人 员 是 从 内 部 看 Linux 内 核 ， 需 要 了 解 
Linux 内 核 的 内 部 实现 机 制 。 

视角 不 同 自然 需求 就 不 同 。 应 用 开发 人 员 需 要 Linux 内 核 提 供 的 功能 ， 主 要 在 用 户 管理 
(包括 用 户 界面 和 用 户 账户 管理 ) 、 系 统管 理 〈 涉 及 资源 分 配 和 时 间 管 理 等 ) 、 数 据 管理 ( 通 
常 通过 文件 系统 相关 接口 实现 ) 和 各 种 网 络 功能 几 个 方面 。 另 外 Linux 内 核 设 计 之 初 就 考虑 
FRA UNIX 的 应 用 ， 所 以 要 求 与 UNIX 功能 接口 一 致 ， 不 能 在 不 同 版 本 中 功能 有 变化 。 针 对 
这 些 特 点 ，Linux 内 核 提 供 和 UNIX 相同 的 应 用 层 接口 即 系统 调用 。 由 于 UNIX AIF AEA 
像 化 系统 ， 所 以 设计 时 并 没有 考虑 图 形 化 操作 的 接口 。 所 以 Linux 内 核 在 开始 的 时 候 并 没有 
像 Windows 那样 考虑 这 部 分 功能 ， 在 内 核 也 没有 图 形 演 染 的 驱动 ， 只 有 通过 字符 设备 这 种 抽 
象 的 功能 和 ioctl 这 种 扩展 性 极 强 的 系统 调用 ， 来 进行 各 种 扩展 。 随 着 系统 的 发 展 ， 现 如 今 
也 提供 了 DRM (direct rendering manager ) 图 形 泻 染 等 功能 ， 来 完善 图 形 化 操作 。 当 然 这 部 
分 功能 并 不 是 通过 增加 新 的 系统 调用 ， 而 是 通过 字符 设备 和 ioctl 系统 调用 来 共同 完成 的 。 
可 见 在 设计 系统 时 ， 关 注 主 要 功能 并 保留 一 个 强大 的 扩展 能 力 是 十 分 重要 的 。 

应 用 层 开 发 人 员 还 有 对 设备 操作 的 需要 ， 但 是 应 用 开发 人 员 不 想 了 解 设备 的 具体 细节 ， 
只 是 想 使 用 设备 完成 一 定 的 功能 。 对 这 些 功 能 的 需求 ， 还 要 求 这 些 功 能 的 实现 在 任何 硬件 上 
都 是 相同 的 ， 也 就 是 硬件 无 关 或 者 说 屏蔽 各 种 硬件 的 差异 。 这 部 分 需求 ， 就 要 求 Linux 内 核 
中 提供 给 应 用 层 的 资源 ， 要 是 虚拟 的 逻辑 资源 ， 不 能 是 物理 资源 ， 通 过 转换 来 实现 对 应 用 层 
统一 的 视角 。 对 于 应 用 层 来 说 硬件 的 无 关 性 需要 操作 系统 支持 各 种 各 样 的 设备 ， 可 以 说 要 支 
持 所 有 的 设备 ， 这 样 应 用 层 可 以 只 关注 其 业务 的 实现 ， 而 不 关心 设备 寄存 带 的 读 写 逻辑 。 

应 用 层 还 有 对 安全 性 的 需求 ， 不 同 的 用 户 所 拥有 的 资源 是 有 限 的 ， 并 且 不 能 超越 权限 访 
问 其 他 用 户 的 资源 。 

Linux 内 核 有 一 类 特殊 的 用 户 ， 就 是 系统 管理 员 ， 这 些 用 户 需 要 对 内 核 有 一 定 的 了 解 ， 
并 对 内 核 进 行 相应 的 设置 。 这 就 需要 内 核 很 多 模块 开放 设置 ,设置 分 为 启动 参数 设置 和 运行 
时 参数 设置 。 设 置 很 大 程度 上 是 进行 系统 调 优 ， 是 为 了 性 能 。Linux 内 核 也 要 满足 性 能 需求 ， 
需要 更 快 、 更 高 、 更 强 。 

内 核 和 驱动 开发 人 员 需 要 Linux 内 核 提 供 基本 功能 和 框架 的 支持 。 他 们 更 多 是 需要 
Linux 内 核 有 良好 的 框架 设计 和 性 能 ， 可 以 使 得 他 们 开发 的 模块 容易 集成 到 内 核 系统 中 ， 并 
且 彼 此 隔离 对 其 他 模块 没有 影响 。 从 内 核 和 驱动 开发 人 员 的 角度 ， 功 能 可 以 分 为 核心 功能 
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设备 相关 功能 两 个 方面 。 
3.2.1 对 内 核 核心 的 需求 探 完 


谈 到 内 核 核 心 需求 ， 先 回忆 一 下 最 小 系统 。 最 小 系统 包括 主 处 理 器 (可 以 理解 为 
CPU) 、 内 存 (RAM), 、 外 部 存储 设备 〈 最 小 系统 中 是 NAND Flash) 、 电 源 管 理 芯 片 以 及 时 
钟 晶 振 。 内 核 核 心 功能 应 该 能 满足 最 小 系统 的 需求 。 从 最 小 系统 的 硬件 出 发 ， 考 虑 内 核 应 该 
满足 的 功能 ， 包 括 程序 管理 功能 、 内 存 管 理 功能 和 存储 管理 功能 ， 当 然 也 对 应 到 这 些 功 能 的 
各 个 层次 的 实现 (在 Linux 内 核 层次 分 析 中 做 过 讨论 )。 男 外 针对 时 钟 晶振 的 硬件 ， 内 核 还 
应 该 提供 时 间 管 理 和 定时 需 管 理 相应 的 功能 。 

最 小 系统 中 最 核心 的 硬件 是 CPU 和 RAM， 在 系统 执行 期 间 这 两 个 硬件 是 必需 的 。 所 以 
这 两 部 分 的 管理 可 以 说 是 Linux 内 核 的 重 中 之 重 ， 对 性 能 等 各 方面 的 影响 也 是 最 大 的 。 对 这 
两 部 分 的 性 能 需求 非常 苛刻 ， 这 也 就 是 这 两 部 分 在 Linux 内 核 中 ， 直 到 今天 还 在 不 断 改进 的 
原因 〈 相 关 改 进 如 将 中 断 处 理 分 成 前 半 部 和 后 半 部 ， 抢 占 式 调度 ， 调 度 算法 演变 为 0(1) 算 
iE, XH CFS 调度 器 或 Deadline 调度 器 等 新 式 调 度 器 ， 内 存 管 理 支 持 大 容量 内 存 ， 大 内 存 
页 等 等 ) 。 可 以 预见 未 来 这 两 部 分 功能 仍然 是 改进 的 重点 ， 但 是 改进 的 方向 应 该 在 SMP 和 多 
核 并 行 运算 ， 以 及 锁 的 效率 上 。 效 率 至 上 在 这 两 部 分 中 体现 特别 明显 ， 只 要 性 能 有 提升 ， 哪 
怕 是 面目 全 非 的 完全 重 写 ， 也 是 必须 做 的 。 图 3-8 中 展示 了 Linux 内 核 这 两 部 分 可 供 各 个 模 
块 使 用 的 功能 ， 从 中 会 看 到 很 多 熟悉 的 函数 ， 后 面 会 进行 比较 全 面 的 介绍 。 

从 图 3-8 中 可 见 ， 体 系 结构 无 关 的 代码 主要 是 在 kernel 以 及 mm 两 个 目录 中 ， 而 与 体系 
结构 相关 的 代码 则 在 arch/xxx/#ll arch/xxx/mm 下 。 可 见 Linux 内 核 在 目录 编排 上 也 是 有 比较 
多 的 讲究 的 ， 这 在 后 续 讨 论 设备 驱动 时 会 有 更 多 介绍 。 

在 图 3-8 中 的 memory 人 硬件 中 除了 RAM 还 有 DMA 和 MMU, 通常 MMU 和 RAM 一 起 实 
现 内 存 管理 ， 而 DMA 作为 底层 的 一 个 横 切 功能 ， 可 以 作为 基础 库 提供 给 不 同 的 设备 驱动 使 
用 。 由 于 DMA 在 便 件 中 的 广泛 使 用 ， 内 核 同 样 需要 在 核心 部 分 提供 该 功能 。 另 外 和 硬件 相 
关 的 底层 横 切 功能 还 包括 clock, GPIO 和 引 脚 管理 等 功能 。 随 着 Linux 的 内 核发 展 这 些 底层 
的 横 切 功能 已 经 逐渐 脱离 具体 的 体系 结构 形成 抽象 库 ， 以 供 Linux 内 核 和 设备 驱动 使 用 。 可 
见 Linux 内 核 核心 功能 需求 也 是 逐渐 发 展 来 满足 内 核 和 驱动 开发 需要 的 。 


3.2.2 对 设备 管理 的 需求 探究 


如 果 对 内 核 代码 进行 统计 ， 会 发 现 超过 百 分 之 五 十 的 代码 都 是 设备 驱动 。 可 见 Linux 内 
核 支 持 了 大 量 的 设备 ， 也 说 明 设备 的 多 样 性 支持 对 于 内 核 的 重要 性 。 应 用 层 需 要 统一 的 接口 
对 设备 进行 操作 ， 内 核 中 还 需要 良好 的 框架 和 机 制 对 这 些 设备 进行 管理 ， 而 很 多 情况 下 还 需 
要 设备 能 够 被 发 现 并 绑 定 正确 的 驱动 (驱动 需要 允许 动态 加 载 )， 这 些 都 是 需要 内 核 框架 的 
支持 。 随 着 蔡 入 式 设备 的 发 展 ， 功 耗 问题 逐渐 成 为 研究 的 重点 ， 这 样 在 框架 方面 也 需要 完 
整 、 统 一 、 简 单 的 实现 ， 以 对 整个 设备 的 使 用 以 及 功 耗 进行 管理 。 所 有 这 些 需求 都 是 需要 在 
各 种 各 样 的 设备 上 实现 ， 实 际 就 会 跨越 不 同 的 设备 类 型 ， 从 而 形成 对 各 种 设备 的 横 切 功能 。 

无 论 是 应 用 层 的 设备 还 是 横 切 功能 ， 在 设备 管理 中 都 是 高 层 的 抽象 概念 。 这 些 抽 象 的 细 
节 如 图 3-9 所 示 ， 图 3-9 中 的 设备 模型 (device model) 就 是 实现 横 切 功能 的 高 级 抽象 模块 ， 
后 续 会 对 设备 模型 进行 详细 讲解 。 横 切 模块 通常 采用 内 骨 的 方式 来 具体 的 实现 。kernel 对 外 
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提供 了 良好 的 接口 sys 文件 系统 ， 可 以 使 用 户 查 看 具体 的 设备 信息 。 关 于 设备 ， 之 前 已 经 介 
绍 用 户 直接 交互 的 设备 主要 是 人 机 接口 (human interface) 设备 ， 人 机 接口 设备 主要 是 通过 
字符 设备 框架 来 做 具体 的 实现 。 一 个 良好 的 设备 实现 框架 ， 如 字符 设备 框架 ， 也 是 设备 开发 
的 重要 和 需求。 其 他 的 需求 ， 如 中 断 框 架 、 地 址 映射 、 内 存 管理 、 定 时 器 等 内 核 核心 功能 模块 
都 是 支撑 驱动 开发 的 基础 。 还 有 一 些 情 况 某 些 设备 中 会 有 子 设备 ， 比 如 现在 的 视频 设备 中 会 
APC 总 线 进行 控制 ， 这 样 在 视频 设备 中 就 需要 使 用 了 C 的 设备 驱动 ， 这 就 要 求 各 种 设备 驱 
动 提供 良好 的 接口 以 便 其 他 设备 在 需要 时 使 用 相应 的 功能 。 这 些 都 是 对 设备 及 设备 开发 的 


HI char devices m interfaces core 


cdev add System Call Interface system files 
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图 3-9 设备 模型 和 抽象 设备 框图 
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3.3 ” 按 需 求 的 设备 分 类 





通常 的 分 类 方式 是 将 设备 分 为 字符 设备 、 块 设备 和 网 络 设备 。 这 种 分 类 方式 在 Linux VIZ 
的 层次 分 析 中 已 经 讨论 过 ， 三 种 设备 面向 完全 不 同 的 三 种 应 用 ， 并 且 它 们 的 数据 组 织 形 式 以 及 
数据 特点 还 是 有 着 明显 的 差别 的 。 字 符 设 备 的 数据 可 以 认为 是 流 式 时 变 的 ; 块 设备 的 数据 是 以 
块 为 数据 单元 的 ; 网 络 设备 的 数据 组 织 形式 是 和 数据 链 路 层 的 数据 组 织 相关 的 。 这 样 的 分 类 方 
式 只 是 在 高 级 抽象 层 中 对 主 设备 相关 的 分 类 ， 对 具体 的 设备 究竟 如 何 划 分 并 没有 涉及 。 

谈 到 设备 分 类 ， 还 会 想到 Linux 内 核 中 的 drivers HX, drivers 目录 下 的 子 目 录 本 身 就 是 
对 设备 驱动 的 分 类 。 图 3-10 是 2. 6. 37 Linux 内 核 drivers 目录 下 的 子 目录 ， 目 录 中 可 以 看 到 
抽象 的 设备 (如 char, block) ， 也 可 以 看 到 具体 的 设备 (Ul media, rte 等 ) ， 有 些 是 和 设备 
以 及 电源 管理 框架 相关 (如 base, power, cpuidle, cpufreq, thermal 等 ) ， 还 有 基于 代码 维 
护 考 虑 创建 的 目录 (如 staging 该 目录 下 的 驱动 还 没有 确认 合并 进 代码 主干 )。 看 到 这 么 多 子 
目录 并 不 清楚 drivers 目录 下 的 驱动 究竟 是 以 什么 原则 进行 子 目 录 的 设计 ， 究 竟 应 该 如 何 将 
设备 进行 分 类 。 由 于 Linux 内 核 中 drivers 目录 下 子 目录 设置 有 代码 管理 的 原因 ， 每 个 子 目 录 
都 对 应 着 Linux 内 核 的 一 个 project。 由 于 Linux 内 核 是 分 布 式 开发 的 ， 通 过 porject 进行 目录 
的 定义 对 代码 管理 来 说 是 比较 好 的 方式 。 随 着 Linux 内 核 的 发 展 ， 目 录 也 在 不 断 地 增加 ， 有 
时 也 会 对 目录 进行 整理 移动 ， 比 如 音频 相关 的 框架 和 驱动 就 移动 到 内 核 的 根 目录 下 的 sound 
























































(base File Folder 
(block, File Folder 
(bluetooth File Folder 
(char File Folder 
G cpufreq File Folder 
(3) cpuidle File Folder 
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(Sy hwmon File Folder 
ize File Folder 
input File Folder 
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Emme File Folder 
mtd File Folder 
(inet File Folder 
(profile File Folder 
(pnp File Folder 
(D power File Folder 
()regulator File Folder 
(arte File Folder 
(scsi File Folder 
(O serial File Folder 
(spi File Folder 
(staging File Folder 
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(thermal File Folder 
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usb File Folder 
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图 3-10 2.6.37 Linux 内 核 drivers 目录 子 目录 
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目录 中 。 
还 有 一 种 设备 分 类 ， 就 是 看 看 内 核 自 己 是 怎么 分 的 。 这 就 要 看 看 内 核 开放 给 我 们 的 接口 
sys 文件 系统 。 新 的 Linux 内 核 在 提供 信息 方面 已 经 做 得 比较 完 

















过 sys 文件 系统 一 探究 竟 。 下 面 是 sys/class 中 的 信息 。 


dongfeng@ DF — WS /sys/class $ ls — al 
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total 0 


drwxr — xr — x 52 root root 0 Dec 10 22:05 . 
dr — xr - xr — x 13 root root O Dec 10 22:05 .. 


drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr — xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 


drwxr - xr - x 


2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 


:05 ata. device 
:05 ata, link 
:05 ata, port 
:05 backlight 
:05 bdi 

:05 block 

:05 bluetooth 
:05 bsg 

:05 devfreq 
:05 dma 

:05 dmi 

:05 drm 

:05 firmware 
:05 gpio 

:05 graphics 
:05 hidraw 
:05 hwmon 
:05 i2c — adapter 
:05 input 

:05 leds 

:05 mdio_bus 
:05 mem 

:05 mise 

:05 mmc_host 
:05 net 

:05 pei bus 
:05 power. supply 
:05 ppdev 

:05 ppp 

:05 printer 
:05 regulator 
:05 rfkill 

:05 rtc 

:05 scsi, device 
:05 scesi. disk 


:05 sesi. generic 


3 


H s 


相应 的 设备 信息 可 以 通 








drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr — xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 


drwxr - xr - x 


2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 


2 root root 0 Dec 10 22; 


2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 
2 root root 0 Dec 10 22 


:05 sesi. host 
:05 sound 

:05 spi. host 

:05 spi master 
:05 spi. transport 
:05 thermal 

:05 timed. output 
:05 tty 

:05 usb 

:05 ve 

05 video4linux 
:05 vtconsole 
:05 watchdog 


` 05 wmi 


从 中 可 以 发 现 ，sys/class 的 信息 oun drivers 目录 下 的 信息 相似 ， 而 且 信息 量 更 大 ， 细 
节 更 多 。 比 如 scsi 就 有 四 个 相关 的 条 目 ，spi 也 有 三 个 相关 的 条 目 。 这 是 由 于 总 线 中 会 有 多 
种 类 型 设备 来 保证 设备 互 连 。 ee 横 切 功能 (如 dma, gpio 等 ) ， 有 些 是 用 户 接 
口 功能 (如 sound, graphic 等 ) , 总 之 是 包含 所 有 类 型 的 信息 。 

讨论 过 数据 操作 形式 的 设备 分 类 、 驱 动 目 录 的 分 类 以 及 sys 文件 系统 分 类 等 方法 后 ， 读 
者 对 实际 设备 如 何 工作 、 驱 动 如 何 实现 仍然 十 分 模糊 ， 而 且 对 实际 设备 的 实现 层次 没有 清晰 



























































的 认识 。 这 里 首先 来 看 看 PC 上 的 硬件 层次 。PC 上 的 硬件 层次 如 图 3-11 所 示 。 
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图 3-11 硬件 层次 图 
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以 图 中 Webcam 为 例 ， 
连接 Webcam， 这 样 硬 件 实 际 就 是 Webcam, USB, PCI 





的 在 驱动 框架 中 也 应 该 有 对 应 的 层次 概念 





的 部 分 是 实现 Webcam 功能 相关 的 模块 ， 








人 硬件 上 从 CPU 到 Webcam 经 过 


了 PCI 总 线 和 USB 总 





线 ， 然 后 才 











三 层 。 硬 件 上 有 了 层次 的 概念 ， 同 样 
。 了 驱动 的 层次 如 图 3-12 所 示 。 图 3-12 中 鸭 起 来 
video. device 是 Webcam 视频 功能 


的 驱动 框架 ,uve_ 





driver 则 是 Webcam 的 具体 实现 驱动 ， 相 应 的 usb_driver 就 是 硬件 层 中 USB 的 具体 实现 。 这 


里 有 个 问题 ， 
USB 总 线 实 现 中 ， 





总 线 的 实现 细节 5. 





为 什么 没有 PCI WE? PCI 如 何 体 现 呢 ?驱动 软件 中 已 经 将 PCI 封装 到 具体 的 
毕竟 USB 设备 本 身 并 不 关心 其 所 在 的 PCI 4 





通过 USB 的 











实现 屏蔽 PCI 的 细节 ， 可 以 让 开发 者 只 关注 直接 关联 的 接口 实现 ， 降 低 实现 的 复杂 度 。 对 硬 
件 的 层次 关系 与 驱动 的 层次 关系 进行 比较 可 以 发 现 ， 人 硬件 的 层次 关系 是 站 在 从 设备 互联 的 角 


度 从 处 理 器 到 功能 设备 ， 而 软件 驱动 的 层次 角 





样 从 硬件 的 层次 需求 出 发 来 理解 设备 驱动 会 更 清晰 、 
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图 3-12 
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度 是 从 功能 











更 明确 。 











到 设备 互联 ， 刚 好 是 反 向 过 程 。 这 


w system run | 
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pci. driver 
pei register driver 
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看 过 Webcam 的 例子 后 ， 再 重新 考虑 设备 分 类 的 问题 ， 硬 件 通过 各 种 总 线 实现 层次 扩 
展 。 那 么 按照 这 种 层次 的 需要 进行 设备 分 类 ， 一 定 会 有 全 新 的 视角 。 再 考虑 Webcam 软件 驱 
动 的 层次 ， 首 先是 功能 的 抽象 ， 然 后 是 设备 连接 的 抽象 ， 这 正好 符合 设备 的 两 个 基本 需 
求 一 一 功能 和 互联 。 设 备 分 类 完全 可 以 从 这 两 个 层次 需求 的 角度 考虑 。 


3.3.1 功能 型 设备 


这 里 先 介绍 功能 型 设备 。 讨 论 到 功能 ， 通 常 都 对 应 到 功能 需求 。Linux 内 核 直接 开放 一 
些 类 型 的 设备 给 用 户 使 用 ， 这 些 类 型 就 是 功能 型 设备 。 通 过 系统 调用 可 以 使 用 功能 型 设备 。 
相应 的 框架 如 图 3-13 所 示 。 
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Driver 





图 3-13 Linux 设备 框架 


从 图 3-13 中 可 见 ， 应 用 之 下 为 一 个 一 个 具体 的 功能 块 ， 如 framebuffer 对 应 于 应 用 图 形 
界面 的 功能 ，V4L (video for Linux) 对 应 于 视频 的 功能 。 这 些 功 能 直接 对 应 于 应 用 的 功能 需 
求 。 还 有 些 特殊 的 需求 可 以 通过 框架 来 进行 扩展 ， 相 应 的 框架 就 是 char 设备 框架 和 block ix 
备 框 架 。 

Linux 内 核 提 供 了 大 部 分 功能 设备 的 框架 ， 详 细 的 信息 可 以 通过 proe 文件 系统 中 的 
devices 文件 获得 。 笔 者 Linux 机 器 上 相应 文件 的 信息 如 下 : 
































dongfeng@ DF - WS /proc $ cat devices 
Character devices ; 
1 mem 
4 /dev/vc/O 
4 tty 
4 ttyS 
5 /dev/tty 
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135 sd 

252 device — mapper 
253 virtblk 

254 mdp 


从 相应 的 信息 中 可 以 看 到 ， 每 种 类 型 前 都 有 一 个 数字 ， 这 个 数字 代表 主 设备 号 。 可 以 说 
Linux 内 核 同 样 考 虑 按 功能 进行 设备 分 类 ， 对 应 的 方式 就 是 为 每 一 类 功能 的 设备 分 配 一 个 主 
设备 号 。 当 然 Linux 为 了 系统 扩展 ， 在 功能 的 基础 之 上 ， 同 时 考虑 数据 处 理 的 特点 ， 进 而 进 
行 抽象 层面 的 分 类 ， 这 就 是 字符 设备 和 块 设备 ， 也 是 更 高 层面 的 抽象 。 在 功能 层面 可 以 不 必 
考虑 像 字符 设备 和 块 设备 这 种 高 层次 的 抽象 ， 而 是 应 更 多 地 关注 功能 框架 本 身 。Linux 内 核 
为 这 些 主 设备 提供 设备 框架 ， 使 得 驱动 开发 者 的 重点 是 在 驱动 框架 的 功能 (如 input, frame 
buffer, v412 和 Alsa 等 ) ， 后 续 章 节 会 对 这 些 功 能 设备 框架 进行 详细 介绍 。 对 于 Linux 内 核 没 
有 提供 的 设备 框架 ，Linux 也 提供 了 一 定 的 扩展 框架 如 mise ( Android 的 binder 就 是 通过 misc 
实现 ) ， 以 及 为 应 用 层 驱动 提供 的 扩展 (如 usb 和 usb_ device) ， 当 然 更 强大 的 功能 扩展 杠 
架 就 是 字符 设备 本 身 。 可 见 Linux 内 核 不 仅 提供 了 比较 完善 的 功能 设备 框架 ， 而 且 为 功能 的 
扩展 提供 了 强大 的 支持 ， 这 些 都 是 为 了 满足 需求 的 多 样 性 ， 以 适应 需求 的 变化 。 


3.3.2 ”总线 型 设备 
总 线 型 设备 的 主要 功能 是 解决 总 线 设备 互 连 的 问题 ， 总 线 互 连 框架 如 图 3-14 所 示 。 
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图 3-14 的 右 侧 是 硬件 连接 示意 图 ，PCI 总 线 上 挂 载 音频 设备 和 USB EZR PE Hil Ae, USB 总 
线 上 连接 的 设备 包括 了 C 总 线 控制 器 和 USB 网 络 设备 ， 而 在 工 C 总线 上 则 连接 一 个 温度 传 感 
器 ， 这 是 典型 的 总 线 层级 连接 ， 涉 及 PCL, USB APC 三 种 总 线 设备 。 图 3-14 的 左 侧 是 软件 实 
现 的 框架 图 ， 可 以 看 到 ， 对 功能 驱动 来 说 ， 其 只 见 到 实际 设备 最 终 连 接 的 总 线 ， 而 整个 连接 层 
次 中 的 其 他 总 线 对 功能 驱动 并 不 可 见 。 这 样 做 的 好 处 就 是 ， 功 能 部 分 只 关心 直接 连接 的 总 线 协 
议 及 其 功能 。 什 么 屏蔽 了 不 同 总 线 连接 的 差异 呢 ? 总 线 控制 器 提供 了 该 功能 。 总 线 控制 器 (如 
USB controller) 在 不 同 的 总 线 之 间 形 成 桥梁 ， 并 管理 自己 总 线 中 连接 的 设备 。 这 样 具体 设备 就 
可 以 直接 和 总 线 控制 器 交互 ， 由 总 线 控制 器 屏 项 总 线 级 联 的 差别 。 

Linux 内 核 同 样 为 开发 者 提供 了 详细 的 总 线 信 息 ， 可 以 通过 /sys/bus 获得 ， 笔 者 Linux 
示 该 日 录 的 信息 如 下 : 
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dongfeng(? DF — WS /sys/bus $ ls -al 
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这 其 中 包含 
pci express 等 ) , 


total 0 


drwxr — xr — x 26 root root 0 Dec 10 22:05 . 
dr — xr - xr — x 13 root root O Dec 10 22:05 .. 


drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 
drwxr - xr - x 


drwxr - xr - x 


4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
5 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 
4 root root 0 Dec 10 22 





Linux 内 核 支 持 的 各 种 总 线 ， 
也 有 虚拟 总 线 (如 platform 等 )。 虚 拟 总 线 是 一 种 逻辑 总 线 ， 


:05 acpi 

:05 clocksource 
:05 cpu 

:05 event_source 
:05 hid 

:05 2c 

:05 machinecheck 
:05 mdio_bus 
:05 memory 

:05 mmc 

:05 node 

:05 pei 

:05 pei express 
:05 platform 

:05 pnp 

:05 rapidio 

:05 scsi 

:05 sdio 

:05 serio 

:05 spi 

:05 usb 

:05 virtio 

:05 xen 

:05 xen - backend 


有 物理 的 总 线 (如 i2c、 


spi, usb, pci, 
主要 是 为 了 满 











足 一 种 逻辑 互 连 功能 。 连 接 的 主体 通常 是 设备 和 对 应 的 驱动 。 总 线 的 一 个 重要 功能 就 是 能 够 
发 现 设备 并 找到 合适 的 驱动 来 操作 设备 ， 这 是 逻辑 总 线 的 主要 功能 。Platform 总 线 主要 是 为 
SoC 内 部 设备 而 设计 的 ， 通 过 该 总 线 可 以 将 设备 属性 和 驱动 分 离 ， 从 而 可 以 使 用 相同 的 驱动 
来 支持 同一 功能 核心 硬件 的 不 同 设备 。 
通过 物理 总 线 和 虚拟 的 逻辑 总 线 ， 可 以 对 Linux 内 核 所 管理 的 设备 进行 更 好 的 组 织 ， 并 
且 可 以 通过 抽象 分 离 属性 和 操作 ， 给 系统 带 来 更 好 的 扩展 性 。 后 续 章 节 会 对 总 线 设备 进行 更 
详细 的 介绍 。 






































3.4 系统 实现 各 种 无 关 性 的 框架 





Linux 内 核 需要 支持 各 种 各 样 的 处 理 器 和 各 种 各 样 的 设备 ， 这 就 要 求 在 框架 设计 时 能 提 
供 更 多 的 灵活 性 。 要 实现 这 些 ，Linux 内 核 需 要 实现 各 种 无 关 性 的 框架 。 其 实 这 些 无 关 性 框 
架 本 身 就 是 设计 模式 。 接 下 来 就 看 看 Linux 内 核 使 用 什么 样 的 模式 解决 这 些 无 关 性 问题 。 


3.4.1 体系 结构 无 关 


首先 Linux 内 核 需要 支持 各 种 处 理 器 ， 也 就 是 要 支持 各 种 体系 结构 。 这 就 要 求 核 心 框架 
与 是 体系 结构 无 关 ， 另 外 编译 系统 可 以 简单 地 支持 各 种 体系 结构 。 

系统 支持 不 同 的 体系 结构 ， 从 软件 管理 的 角度 考虑 ， 一 个 简单 的 办 法 就 是 将 不 同体 系 结 
构 的 代码 放 入 不 同 的 目录 。Linux 内 核 也 是 如 此 实现 的 ， 如 图 3-15 所 示 。 


























(alpha File Folder 
(arm File Folder 
Davraz File Folder 
(E blackfin File Folder 
Ecris File Folder 
(carre File Folder 
ha300 File Folder 
四 ia64 File Folder 
m3r File Folder 
meek File Folder 
加 mi3knommu File Folder 
microblaze File Folder 
(mips File Folder 
加 mni0300 File Folder 
parisc File Folder 
(powerpc File Folder 
(ys390 File Folder 
score File Folder 
(ash File Folder 
sparc File Folder 
(tile File Folder 
(um File Folder 
(x86 File Folder 
(C tensa File Folder 


图 3-15 Linux 内 核 体系 结构 相关 代码 目录 


接 下 来 就 要 在 编译 系统 中 解决 相应 的 问题 。 在 Linux 内 核 根 目录 下 的 Makefile 中 包含 如 
下 内 容 : 
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# Architecture as present in compile. h 
UTS MACHINE:- $ (ARCH) 
SRCARCH:- $ ( ARCH) 


# Additional ARCH settings for x86 

ifeq ( $ (ARCH) , i386) 
SRCARCH := x86 

endif 

ifeq ( $ (ARCH) ,x86. 64) 
SRCARCH := x86 

endif 


3t Additional ARCH settings for sparc 

ifeq ( $ ( ARCH) ,sparc32) 
SRCARCH := spare 

endif 

ifeq ( $ (ARCH) , sparc64 ) 
SRCARCH := spare 

endif 


# Additional ARCH settings for sh 

ifeq ( $ (ARCH) ,sh64) 
SRCARCH := sh 

endif 


# Where to locate arch specific headers 


hdr -arch := $ (SRCARCH) 


ifeq ( $ (ARCH) ,m68knommu) 
hdr -arch := m68k 


vmlinux -lds :=arch/ $ (SRCARCH) /kernel/vmlinux. Ids 














可 见 Linux 内 核 通过 宏 变量 ARCH 来 定义 具体 的 体系 结构 ， 并 由 宏 变 量 SRCARCH 来 定 
义 具 体 的 体系 结构 相关 代码 目录 。 首 先 ，ARCH 转换 为 正确 的 体系 结构 源 代码 目录 ， 然 后 使 
用 体系 结构 相关 的 Makefile 文件 ， 这 里 直接 引入 相应 目录 的 文件 。 还 有 一 个 重要 的 文件 需要 
设 定 ， 这 就 是 链接 文件 (由 于 不 同 的 体系 结构 使 用 的 地 址 空间 会 有 差别 ) vmlinux-lds。 可 
以 看 到 编译 不 同 的 体系 结构 代码 只 要 根据 体系 结构 设 定 ARCH 宏 即 可 。 
解决 了 编译 的 问题 ， 就 要 看 一 下 具体 的 实现 如 何 做 到 体系 结构 无 关 了 。 做 到 体系 结构 无 
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关 采 用 的 技术 就 是 分 层 ， 将 系统 分 为 体系 结构 相关 层 和 设备 控制 层 (将 体系 结构 相关 代码 
封装 为 统一 接口 ) 。 这 样 设 备 控制 层 之 上 的 代码 就 是 体系 结构 无 关 的 代码 ， 就 可 以 在 不 同 的 
处 理 器 上 重用 了 。 具 体 的 实现 如 图 3-16 所 示 。 


CPU 


interrupt 
vires usu APIC 
registers APIC controller 





图 3-16 Linux 内 核 体 系 结构 无 关 具 体 实现 


从 图 3-16 中 可 见 ， 体 系 结构 相关 的 主要 部 分 是 中 断 、 任 务 切换 、 寄 存 咒 、 系 统 调用 
以 及 系统 初始 化 。 只 要 把 这 几 部 分 通过 统一 接口 封装 ， 就 可 以 在 代码 级 别 实现 体系 结构 
无 关 。 
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3.4.2 功能 型 设备 的 框架 与 总 线 无 关 

在 物理 设备 中 ， 同 样 的 总 线 可 以 连接 不 同 的 设备 ， 同 样 功 能 的 设备 可 以 通过 不 同 的 总 线 
使 用 ， 这样 就 需要 软件 框架 中 能 够 解决 功能 和 总 线 无 关 的 问题 。 下 面 以 SPI 总 线 为 例 说 明 
Linux 内 核 是 如 何 解 决 该 问题 的 。 如 图 3-17 所 示 。 
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drivers/spi/atrnel_spi.c 
SPI Adapter Driver 
platform_driver 





drivers/spi/amba-p1022.c 
SPI Adapter Driver 
amba_driver 





drivers/spi/mpc52xx_spi.c 
SPI Adapter Driver 
at_platform_driver 


SPI Adapter Driver 
platform_driver 








drivers/spi/spi_imx.c 





SPI Adapter Drivers 


图 3-17 功能 框架 与 SPI 总 线 设备 机 


图 3-17 顶部 为 Linux 内 核 的 各 种 框架 ， 包 括 对 用 户 的 功能 和 横 切 功能 ; 中 间 的 SPI Core 
则 是 处 理 SPI 总 线 事务 ， 这 两 者 是 完全 隔离 的 ， 它 们 之 间 的 代码 是 无 关 的 。 当 然 对 特定 的 设 
备 需要 在 功能 和 总 线 操 作 之 间 建 立 一 座 桥梁 ， 这 座 桥梁 就 是 具体 功能 的 SPI 设备 驱动 。 具 体 
功能 的 总 线 驱 动 会 在 相应 的 功能 操作 和 总 线 事 务 之 间 进行 转化 ， 从 而 将 两 个 独立 的 框架 结合 
起 来 。 

通过 功能 框架 、 总 线 框架 和 特定 功能 的 总 线 驱 动 三 者 的 有 机 结合 和 协调 工作 ， 就 可 以 实 
现 功能 框架 和 总 线 无 关 。 驱 动 开 发 人 员 开 发 特定 功能 的 总 线 驱 动 时 ， 任 务 十 分 明确 ， 就 是 在 
特定 的 功能 操作 和 总 线 事务 之 间 做 转换 。 每 个 部 分 的 功能 需求 明确 ， 才 会 有 系统 性 能 优良 、 
可 维护 性 好 的 实现 。 


总 线 控制 器 与 总 线 设备 的 无 关 


对 总 线 来 说 ， 总 线 设备 的 多 样 性 是 一 个 方面 ， 另 一 个 方面 处 理 器 中 对 总 线 的 管理 也 是 多 
样 的 。 比 如 USB 总 线 ，Intel 处 理 器 的 总 线 管理 设备 〈 即 总 线 控制 器 ) A ARM 处 理 器 的 总 线 
管理 设备 就 有 很 大 的 差别 。 总 线 上 连接 的 设备 并 不 想 知道 自己 具体 和 哪些 总 线 管 理 设 备 进 行 
交互 。 总 线 控制 器 只 关注 于 具体 的 总 线 操作 ， 所 以 总 线 控制 器 也 并 不 关心 连接 在 总 线 上 的 设 
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3.4.3 


备 如 何 使 用 总 线 实 现 其 功能 。 总 线 控制 器 是 一 个 服务 管理 的 实体 ， 要 能 为 所 有 连接 到 总 线 上 
的 设备 进行 服务 ， 并 管理 它们 ， 不 至 于 彼此 冲突 。 

可 见 总 线 控制 器 和 总 线 设备 两 者 要 完成 的 任务 有 联系 ,但 是 彼此 不 能 限定 对 方 ， 这 就 要 
求实 现 总 线 控制 器 和 总 线 设备 的 无 关 。 

图 3-18 和 图 3-19 分 别 展示 了 Linux 内 核 在 USB FI PC 总 线 框架 上 如 何 实现 总 线 控制 器 
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Controller 


图 3-18 USB 总线 框架 

从 图 3-18 和 3-19 中 可 见 ， 不 同 的 总 线 框架 解决 总 线 控制 器 和 总 线 设 备 无 关 是 使 用 了 
相同 的 方法 ， 就 是 抽象 出 总 线 核心 来 管理 总 线 控制 器 和 总 线 设 备 ， 并 将 两 者 有 机 的 结合 。 对 
于 USB 总 线 有 USB Core， 对 于 工 C BAA PC Core， 都 是 完成 总 线 核心 的 功能 。 

可 见 总 线 核心 是 要 同时 管理 总 线 控制 器 和 总 线 设备 的 。 如 图 3-20 所 示 ， 以 USB 总 线 为 
例 展 示 了 Linux 内 核 如 何 实现 该 功能 。 

从 图 3-20 中 可 见 ， 无 论 是 总 线 控制 器 USB adapter 还 是 总 线 设备 USB device 都 会 注册 到 
USB core 中 ， 这 样 USB core 就 可 以 对 两 者 进行 管理 。 这 其 中 的 管理 还 包括 在 两 者 之 间 进 行 
必要 的 绑 定 ， 比 如 说 连接 到 USB 总 线 控制 器 的 USB 设备 ， 其 操作 必然 要 经 过 该 总 线 控制 器 
完成 。 这 种 绑 定 都 可 以 通过 USB 设备 发 现 由 USB Core 自动 完成 。 
通过 这 些 方 法 就 能 够 实现 总 线 控制 器 和 总 线 设备 无 关 。 
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图 3-19 PC 总 线 框架 
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USB Adapter USB Adapter USB Device USB Device USB Device 
driver A driver B driver 1 driver 2 driver 3 
f | DEV1 | DEV2 
USB1 
System DEV3 | DEV4 REN? 
USB2 
图 3-20 Linux 内 核 USB 管理 框架 
3.4.4 设备 属性 和 设备 操作 无 关 
图 3-20 中 不 仅 涉 及 总 线 控制 器 和 总 线 设备 无 关 的 问题 ， 还 展示 了 男 一 个 问题 ， 就 是 








同一 个 设备 驱动 应 该 可 以 支持 多 个 设备 。 如 USB device driver 1 就 同时 支持 DEVI 和 


DEV3 ， 这 就 需要 使 设备 
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属性 和 设备 操作 无 关 。 如 何 解决 该 问题 呢 ? 之 前 的 无 关 性 解决 办 











法 已 经 给 了 提示 ， 就 是 将 需要 做 到 无 关 的 两 部 分 都 抽象 出 来 ， 形 成 两 个 实体 单独 管理 。 
对 设备 操作 就 抽象 出 操作 接口 ， 形 成 驱动 的 主要 操作 功能 。 将 设备 属性 等 信息 抽象 出 来 





形成 设备 结构 ,不同 的 设备 就 可 以 有 不 同 的 属性 ， 而 作为 操作 接 




















口 ， 则 通过 从 设备 结构 











中 获得 的 属性 进行 操作 ， 就 可 以 把 设备 属性 形成 的 具体 设备 和 设备 操作 形成 的 设备 驱动 
区 分 开 并 单独 进行 管理 。 





下 面 是 Linux 内 核 中 串口 部 分 的 数据 结构 ， 从 中 可 以 看 





两 者 分 离 的 。 


代表 设备 的 uart_ port 中 包含 了 各 种 








struct uart_port | 





E 性 信息 : 


spinlock t lock ; / * port lock */ 
unsigned int — iobase; /* in/out[ bwl] * / 
unsigned char _iomem * membase; / * read/write[ bwl] * / 
unsigned int irq; /'* irq number */ 
unsigned int — uartclk ; / * base uart clock */ 
unsigned char fifosize ; / * tx fifo size */ 
unsigned char x_char; / * xon/xoff flow 

control * / 
VIA 


E 


代表 驱动 的 设备 操作 结构 ， 其 中 包含 了 各 种 操作 接口 ， 注 意 操 作 接 口 通常 都 要 有 设备 
性 结构 作为 参数 ， 这 样 可 以 适用 于 不 同 的 设备 











struct uart_ops | 


l; 


uint ( * tx empty) (struct uart_port * ) ; 

void ( * set, metrl) (struct uart_port * , 
unsigned int mctrl) ; 

uint ( * get, metrl) (struct uart_port * ) ; 

void ( * stop. tx) (struct uart, port * ) ; 

void ( * start, tx) (struct uart, port * ) ; 

J# Lo. RS 

void ( * shutdown) (struct uart_port * ) ; 

void ( * set termios) ( struct uart_port * , 

struct termios * new, 


struct termios * old) ; 


VES sua dE 

void ( * config port) (struct uart_port * , 
int) ; 

A eps SYA 


H Linux 内 核 是 如 何 抽象 从 而 将 





BE: 








E 





/* Is TX FIFO empty? */ 


/ * Set modem control params * / 


/ * Get modem control params * / 


/ * Stop xmission * / 


/ * Start xmission * / 


/ * Disable the port */ 


/ * Set terminal interface 


params */ 


/ * Configure UART port * / 
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具体 两 者 绑 定 操作 通常 在 总 线 级 别 完成 。 没 有 物理 总 线 的 设备 可 以 通过 逻辑 总 线 (如 
platform 总 线 ) 完成 。 

可 见 要 实现 设备 属性 和 设备 操作 无 关 ， 不 仪 是 设备 和 驱动 之 间 的 问题 ， 还 要 涉及 高 级 别 
的 抽象 即 总 线 ， 通 过 总 线 将 两 者 互 连 绑 定 。 这 部 分 可 以 扩展 到 具体 的 驱动 以 及 Linux 内 核 中 
的 设备 模型 相关 的 内 容 ， 后 续 会 有 更 详细 的 说 明 。 


3.4.5 策略 和 机 制 无 关 


现实 生活 中 会 有 不 同 的 人 使 用 相同 的 工具 解决 同一 个 问题 。 由 于 人 的 不 同 ， 解 决 问题 的 
方法 就 不 同 ， 即 使 使 用 相同 的 工具 ， 有 具体 的 操作 方式 也 会 有 差别 。 在 系统 设计 方面 ， 由 于 系 
统 是 十 分 复杂 的 ， 要 解决 一 个 问题 时 ， 不 同 的 情况 下 采用 不 同 的 方法 会 有 不 同 的 效果 ， 这 和 
现实 生活 中 使 用 工具 解决 问题 是 类 似 的 。 在 Linux 内 核 中 也 面临 同样 的 问题 ， 只 是 把 基本 的 
工具 理解 为 机 制 ， 而 具体 操作 工具 的 方式 方法 理解 为 策略 问题 。 这 样 系统 就 要 实现 策略 和 机 
制 无 关 。 

Al 3-21 是 Linux 内 核 中 CPUFreq 的 架构 ， 其 中 涉及 到 该 架构 中 如 何 解决 策略 和 机 制 的 
方法 。 





























































CPUFreq 
policy 


CPUFreq 
controller 


System 
status 





target frequency 





CPUFreq 
CPU 
driver 








change frequency 





software 
hardware 





A] 3-21  CPUFreq 架构 


图 3-21 中 CPU driver 代表 了 机 制 ， 而 CPUFreq policy 则 是 具体 进行 CPU 主 频 选 择 的 策 
it, CPUFreq controller 根据 当前 系统 的 状态 和 当前 选择 的 策略 选择 合适 的 CPU 主 频 ， 通 过 
CPU driver 进行 设置 。 从 其 过 程 可 以 看 出 ， 机 制 〈( 即 对 CPU 设置 一 定 的 频率 ) 和 策略 ( 什 
么 情况 下 选择 什么 频率 ) 已 经 分 离 。 这 样 就 可 以 通过 相同 的 机 制 支持 不 同 的 策略 ， 通 过 对 
策略 的 选择 ， 使 得 系统 随 需 而 变 。 

具体 的 机 制 和 策略 无 关 ，Linux 内 核 中 还 有 很 多 体现 ， 后 续 会 有 更 详细 的 说 明 。 
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3.5 内核 提供 的 基本 服务 和 接口 简介 





Linux 内 核 的 使 用 环境 和 应 用 层 的 程序 完全 不 同 ， 主 要 在 于 有 很 多 资源 的 限制 ， 如 栈 容 











量 的 限制 ， 内 存 不 一 定 是 连续 物理 空间 的 限制 等 等 。 由 于 这 些 限 制 ， 应 用 层 的 库 函 数 就 不 能 
直接 在 Linux 内 核 中 使 用 ， 但 是 有 很 多 功能 确实 是 Linux 内 核 中 各 个 模块 都 需要 的 。 这 就 需 


要 Linux 内 核 提 供 类 似 C 库 功 能 的 函数 库 ， 以 适应 内 核 有 限 的 资源 ， 并 为 Linux 内 核 的 其 他 
模块 使 用 。 进 行 Linux 内 核 和 驱动 程序 的 开发 自然 需要 熟悉 这 些 基本 服务 和 接口 。 下 面具 体 





介绍 kernel API。 


3.5.1 基本 数据 类 型 


1. 双向 链表 
双向 链表 的 数据 结构 如 下 : 


struct list_head | 


struct list_head * next, * prev; 


ls 


入 到 具体 的 结构 中 ， 所 以 需要 通过 双向 链表 查找 到 具体 的 包含 双向 链表 的 结构 体 指针 ， 该 操 








作 通 过 宏 container_of 完成 ， 具 体 如 下 : 





#define container of(ptr, type, member) ( | 


\ 


const typeof( ( (type * )0) -> member) * _mptr = (ptr); V 
(type * ) ( Cchar * ) mptr — offsetof( type, member) ) ; | ) 


对 双向 链表 的 具体 操作 如 下 : 


list_add 
list_add_tail 





向 链表 添加 一 个 条 目 








添加 一 个 条 目 到 链表 尾部 


__list_del_entry 一 一 从 链表 中 删除 相应 的 条 目 





list_replace 
list_del_init 


从 





list_move 


list_move_tail 





list_is_last 


list_empty——ll 


list_empty_careful 


list_rotate_left 





list_is_singular 


list, cut. position 





list. splice 


用 新 条 目 蔡 换 旧 条 目 


























从 链表 中 删除 条 目 后 重新 初始 化 
一 个 链表 中 删除 并 加 入 为 另 一 个 链表 的 头 部 
从 一 个 列表 中 删除 并 加 入 为 男 一 个 链表 的 尾部 














测试 是 否 为 链表 的 最 后 一 个 条 目 





I 试 链表 是 否 为 空 
测试 链表 是 否 为 空 并 没有 被 修改 
向 左 转动 链表 

测试 链表 是 否 只 有 一 个 条 目 


将 链表 一 分 为 二 











将 两 个 链表 进行 合并 
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list_splice_tail 








list_splice_init 





erm 


list, entry ——3X INA 目的 结构 ， 











list_first_entry 一 一 获 取 链 表 的 第 一 
获取 链表 的 第 





list_first_entry_or_null 


遍历 链表 





list_for_each 





list_for_each_prev 





list_for_each_safe 


反 向 遍历 链表 
遍历 链表 并 删除 链表 中 相应 的 条 


并 为 一 个 链表 
并 为 一 个 链表 并 初始 化 为 空 表 


AH 














个 元 素 
一 个 元 素 





目 

















list_for_each_prev_safe 
list_for_each_entry 一 一 遍历 指定 


list_for_each_entry_reverse 





反 


反 向 遍历 链 
类 型 的 链表 











并 删除 链表 中 相应 的 条 目 





向 遍历 指定 类 型 的 链表 


list_prepare_entry 一 一 准备 一 个 用 于 list_for_each_entry_continue 的 条 目 





list_for_each_entry_continue 








list. for each. entry. from 








list. for each. entry, safe 


list, for each. entry, safe continue 








list, for each. entry, safe from 





list. for each. entry, safe. reverse 








list safe reset next 





hlist for each, entry. continue 


从 
list_for_each_entry_continue_reverse 
从 当前 点 遍历 指 
反 疝 裔 历 指定 类 型 的 链表 并 





从 当前 点 遍历 链表 并 删 
反 向 遍历 链表 并 删除 链表 中 相应 的 条 





获得 下 一 个 
hlist_for_each_entry 一 一 遍历 指定 类 型 的 单 指针 表 头 链表 


定点 开始 继续 遍历 指定 类 型 的 链表 
从 指定 点 开始 反 向 遍历 链表 
定 类 型 的 链表 

删除 链表 中 相应 
继续 遍历 链表 并 删除 链表 中 相应 的 条 
































间 定 类 型 的 条 目 





从 当前 点 继续 遍历 单 指针 表 头 链表 











hlist_for_each_entry_from 





hlist_for_each_entry_safe 


2. 字符 串 相 关 
内 核 中 经 常会 


变换 一 个 字符 





simple. strtoull 





simple. strtoul 








simple, strtol 





变换 一 
格式 化 一 
格式 化 一 个 字符 串 


个 字符 





simple_strtoll 





vsnprintf 








vsenprinttf- 





snprintf: 


格式 化 一 





scnprintf: 





vsprintf 





sprintf 





vbin_printf 解析 格式 化 字符 是 


遍历 指定 


格式 化 一 个 字符 串 并 放 入 缓冲 区 
个 字符 串 并 放 入 缓冲 区 
格式 化 一 个 字符 串 并 放 入 缓冲 区 
格式 化 一 个 字符 串 并 放 入 缓冲 区 


从 当前 点 继续 遍历 单 指针 表 头 链表 





除 链 表 中 相应 的 条 


的 条 目 


目 
目 





目 

















类 型 的 单 指 针 表 头 链表 并 删除 链 


字符 串 转换 的 需要 ， 其 接口 如 下 : 





串 为 无 符号 的 long long 型 


变换 一 个 字符 串 为 无 符号 的 long 型 
变换 一 个 字符 串 为 有 符号 的 long 型 





和 为 有 符号 的 long long 型 





个 字符 串 并 放 入 缓冲 区 


并 放 入 缓冲 区 

















串 并 将 二 进 制 值 放 入 缓冲 区 














bstr. printf 
bprintf 





对 二 进 制 参 数 进行 格式 化 字符 串 操 作 3 
解析 格式 化 字符 串 并 将 二 进 制 值 放 入 缓冲 区 








: 放 入 缓冲 区 











中 相应 


ep i ee MEE SHE 
实现 对 container_of 的 封装 


的 条 目 


vsscanf- 





sscanf- 





kstrtol 
kstrtoul 
kstrtoull 





kstrtoll 
kstrtouint 
kstrtoint 

















变换 


BE 


从 格式 化 字符 上 

















一 个 字符 串 为 long long 型 


换 一 个 字符 串 为 无 符号 的 int 型 
变换 一 个 字符 串 为 nt 型 








另外 字符 串 本 身 的 操作 接口 如 下 : 


为 无 符号 的 long 型 
为 无 符号 的 long long 型 


中 分 离 出 的 参数 列表 
从 格式 化 字符 串 中 分 离 出 的 参数 列表 
变换 一 个 字符 串 为 long 型 
变换 一 个 字符 
变换 一 个 字符 


strnicmp 一 一 长 度 有 限 的 字符 串 比较 ,这 里 不 分 大 小 写 





strepy 
strncpy 





strlepy 





strcat: 





strncat 





strlcat 











在 字符 


复制 一 个 以 NULL 结尾 的 字符 串 
复制 一 个 以 NULL 结尾 的 有 限 长 度 字符 串 








复制 一 个 以 NULL 结尾 的 有 限 长 度 字 符 唱 
后 附加 以 NULL 结尾 的 字符 
在 字符 串 后 附加 以 NULL 结尾 的 一 定 长 度 的 字符 串 
在 字符 串 后 附加 以 NULL 结尾 的 一 定 长 度 的 字符 串 
stremp 一 一 比较 两 个 字符 串 
stmcmp 一 一 比较 两 个 限定 长 度 的 字符 串 






































hH 
5] 


























strchr 一 一 在 字符 串 中 查找 第 一 个 出 现 指定 字符 的 位 置 
strchr 一 一 在 字符 串 中 查找 最 后 出 现 指 定 字 符 的 位 置 
stmchr 一 一 在 字符 串 中 查找 出 现 指定 字符 串 的 位 置 





skip_spaces 


strim 一 一 从 字符 串 中 移 除 前 置 及 后 置 的 空格 
获得 字符 串 的 长 度 





strlen: 

















从 字符 串 中 移 除 前 置 空格 























strnlen 获得 



































个 有 限 长 度 字 符 串 的 长 度 
















































































B IZ wp x H 





strspn 一 一 计算 一 个 仅 包含 可 接受 字母 集合 的 字符 串 的 长 度 
strespn 计算 一 个 不 包含 指定 字母 集合 的 字符 串 的 长 度 
strpbrk 一 一 找到 字符 集合 在 字符 串 第 一 次 出 现 的 位 置 
strsep 分 割 字符 串 

sysfs_streq 字符 串 比 较 , 用 于 sysfs 

strtobool 用 户 输入 转换 成 布尔 值 

memset 内 存 填充 

memcpy 内 存 复 制 

memmove 内 存 复制 

memcmp 一 一 内 存 比较 

memscan 一 一 在 内 存 中 找 指定 的 字符 

strstr 一 一 在 一 个 以 NULL 结尾 的 字符 串 中 找到 第 一 个 子 串 





strnstr 
memchr 


memchr inv 





在 一 个 限定 长 度 字符 串 


RF 











| 内 存 中 的 字符 
找到 内 存 中 的 不 匹配 字符 








Pd SIS TT 


3. 位 操作 
内 核 中 很 多 地 方 需要 位 操作 ， 比 如 磁盘 管理 等 对 空间 管理 的 功能 。 


设置 内 存 中 指定 位 
设置 内 存 中 指定 位 
清除 内 存 中 指定 位 
改变 内 存 中 指定 位 
改变 内 存 中 指定 位 

内 存 中 指定 位 并 返回 
设置 内 存 中 指定 位 并 
设置 内 存 中 指定 位 并 返回 旧 值 
清除 内 存 中 指定 位 并 返回 旧 值 
清除 内 存 中 指定 位 并 返回 旧 值 
改变 内 存 中 指定 位 并 返回 旧 值 





H 








set. bit 




















. set bit 








clear. bit 





. change bit 





change. bit 


设置 








日 值 
返回 旧 值 


test_and_set_bit 























test_and_set_bit_lock 




















. test and set bit 








test and. clear bit 




















. test and clear bit 














test, and. change bit 





























test_bit 一 一 测试 内 存 中 某 一 位 是 否 设 置 

— ffs 找到 word 里 的 第 一 个 设置 位 

ffz 找到 word 里 的 第 一 个 零 位 

ffs 找到 word 里 的 第 一 个 设置 位 

fls 找到 word 里 的 最 后 一 个 设置 位 

fls64 找到 64 位 word 里 的 最 后 一 个 设置 位 


3.5.2 基本 原子 操作 


处 理 器 中 很 多 单元 都 可 以 对 RAM 进行 操作 ， 这 就 需要 考虑 并 发 访问 的 问题 ， 特 别 是 一 
些 变量 的 操作 ， 需 要 有 原子 操作 的 接口 。Linux 内 核 中 这 样 的 操作 也 是 很 多 的 ， 而 且 Linux 
内 核 还 需要 面 对 多 体系 结构 的 问题 。 为 了 在 这 方面 简化 开发 人 员 的 操作 ，Linux 内 核 提 供 了 
体系 结构 无 关 的 原子 操作 接口 。 











读 原子 量 

设置 原子 量 

在 原子 量 中 增加 整数 

从 原子 量 中 减 去 整数 

从 原子 量 中 减 去 整数 并 测试 结 
增加 原子 量 

减少 原子 量 





atomic. read 





atomic. set 





atomic. add 








atomic. sub 


7 也 








atomic_sub_and_test 








atomic, inc 





atomic, dec 





atomic. dec. and test 
atomic. inc. and test 
atomic, add. negative 
atomic. add. return 
atomic. sub. return 
. atomic. add. unless 


atomic. inc. short 





atomic, or long 
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减少 并 测试 
增加 并 测试 

增加 并 测试 是 否 为 负 
增加 整数 并 返回 
减少 整数 并 返回 
增加 到 给 定 值 为 止 
增加 一 个 短 整 数 


或 两 个 长 整数 


3.5.3 


延 时 、 调 度 、 定 时 如 相关 


Linux 内 核 通常 会 对 某 些 操作 等 待 一 定 的 时 间 后 ， 再 确认 操作 完成 。 根 据 系统 的 需要 这 
种 延 时 操作 有 不 同 的 实现 方式 ， 主 要 包括 延 时 、 调 度 和 定时 器 等 几 种 不 同 的 方法 。 有 时 还 要 











检查 系统 所 处 的 状态 ， 具 体 的 接口 如 下 : 





pid_alive 检查 一 个 进程 是 否 过 期 

检查 一 个 进程 的 结构 体 是 否 初始 化 

一 个 指定 的 进程 是 否 空闲 

锁定 线程 组 

解锁 线程 组 

唤醒 一 个 特定 的 进程 

抢占 或 者 调度 事件 的 通知 注册 接口 
取消 接收 抢占 或 者 调度 事件 的 通知 

唤醒 等 待 队列 中 挂 起 的 线程 

唤醒 等 待 队 列 中 挂 起 的 线程 

对 等 待 完成 量 的 单一 线程 发 信号 

对 等 待 完成 量 的 所 有 线程 发 信号 

在 完成 量 上 等 待 直到 其 处 于 完成 状态 

在 完成 量 上 等 待 直到 其 处 于 完成 状态 ,允许 超时 退出 

在 完成 量 上 等 待 直到 其 处 于 完成 状态 

在 完成 量 上 等 待 直到 其 处 于 完成 状态 ,允许 超时 退出 
在 完成 量 上 等 待 直到 其 处 于 完成 状态 ,允许 信号 中 断 
在 完成 量 上 等 待 直到 其 处 于 完成 状态 

在 完成 量 上 等 待 直到 其 处 于 完成 状态 ,允许 杀 死 该 进程 
在 完成 量 上 等 待 直到 其 处 于 完成 状态 

尝试 对 完成 量 进行 非 阻 塞 的 减少 操作 

检查 是 否 有 进程 等 待 完成 量 

返回 给 定 任务 的 调度 nice 值 

sched_setscheduler 一 一 改变 一 个 线程 的 调度 策略 或 优先 级 

yield 放弃 处 理 需 ,触发 调度 
yield_to 一 一 放弃 处 理 带 给 同 线程 组 中 的 其 他 线程 

找到 系统 中 最 好 的 (最 低 优先 级 ) 的 处 理 需 

更 新 处 理 需 优先 级 设置 

初始 化 处 理 器 优先 级 结构 

清除 处 理 需 优先 级 结构 

获取 给 定 进程 调度 域 的 负载 指数 

更 新 进程 调度 组 的 负载 均衡 统计 

最 忙 的 组 返回 真 

update. sd. Ib. stats 更 新 进程 调度 域 的 负载 均衡 统计 

检查 此 组 是 否 能 加 入 相应 的 调度 域 

在 负载 均衡 阶段 计算 一 个 进程 调度 域 中 各 组 间 存 在 的 次 要 不 平衡 





is_global_init 








is_idle_task 





threadgroup_lock 





threadgroup_unlock 





wake_up_process 
































preempt_notifier_register 


























preempt_notifier_unregister 





. wake up 





. Wake up. sync. key 





complete 








complete. all 














um 


wait. for completion 




















wait for completion, timeout 








wait for completion, io 











wait for completion. io. timeout 





wait for completion, interruptible 











wait for completion. interruptible timeout 











wait for completion, killable 








wait for completion, killable timeout 





try. wait, for completion 








completion, done 








task, nice 























cpupri. find 








cpupri set 








cpupri init 








cpupri, cleanup 








get sd load idx 





update sg lb stats 





update sd. pick. busiest 











check asym. packing 











fix, small. imbalance 
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calculate_imbalance 


find_busiest_group 


DECLARE_COMPLETION 一 一 声明 并 初始 化 一 个 完成 量 结构 














在 负载 均衡 阶段 计算 当前 进程 调度 域 中 各 组 目前 不 平衡 数目 
如 有 不 平衡 返回 进程 调度 域 中 最 忙 的 一 个 组 








DECLARE_COMPLETION_ONSTACK 一 一 声明 并 初始 化 一 个 完成 量 结构 





init_completion 


INIT_COMPLETION 





. round, jiffies 


. round, jiffies relative 





round jiffies 
round jiffies relative 


. round, jiffies up 


_ round, jiffies up. relative 





round jiffies up 


round jiffies up. relative 





set timer slack 





init timer key 


mod, timer pending 





mod, timer 


mod, timer. pinned 


初始 化 一 个 动态 分 配 的 完成 量 














设置 定时 器 允许 的 
初始 化 一 个 定时 右 











重新 初始 化 一 个 完成 量 结构 





返回 精确 到 秒 的 jiffies 值 


返回 精确 到 秒 的 jiffies 值 





返回 精确 到 秒 的 jiffies (B 


返回 精确 到 秒 的 jiffies {EL 
返回 精确 到 秒 的 jiffies 值 ,返回 值 大 于 原 值 
返回 精确 到 秒 的 jiffies 值 ,返回 值 大 于 原 值 








返回 精确 到 秒 的 jiffies 值 ,返回 值 大 于 原 值 








返回 精确 到 秒 的 jiffies 值 ,返回 值 大 于 原 值 
IES 





修改 一 个 挂 起 定时 器 的 超时 时 间 


修改 一 个 定时 器 的 超时 时 间 


修改 一 个 定时 噩 的 超时 时 间 


























add_timer 始 一 个 定时 需 
add_timer_on 在 特定 的 处 理 器 上 开始 一 个 定时 器 
del_timer 关闭 一 个 定时 器 


try. to. del. timer. sync 





del timer sync 


schedule. timeout 





msleep 


msleep. interruptible 





usleep range 


3.5.4 锁 操 作 


作为 复杂 系统 ， 不 同 模块 之 间 一 定 有 公共 操作 部 分 。 对 公共 部 分 的 访问 是 需要 锁 保 护 的 。 











尝试 关闭 一 个 定时 上 顺 


关闭 一 个 定时 器 并 等 竺 处理 程序 的 完成 
休眠 直到 超时 
毫秒 级 休眠 











毫秒 级 休眠 可 以 被 信号 唤醒 


微 秒 级 休 眼 





Linux 内 核 中 有 上 下 文 的 概念 ， 包 括 中 汤 上 下 文 和 进程 上 下 文 ， 这 两 个 上 下 文 之 间 对 共同 数据 
的 访问 同样 需要 保护 。 另 外 现代 处 理 器 中 通常 包含 多 核 (SMP) ， 不 同 的 核 很 可 能 访问 相同 的 
数据 ， 这 样 也 需要 保护 。Linux 内 核 为 了 支持 不 同形 式 的 数据 保护 提供 了 各 种 锁 机 制 。 

针对 SMP、 中 断 上 下 文 、 进 程 上 下 文 的 数据 访问 保护 ，Linux 内 核 提供 了 自 旋 锁 相关 的 








锁 机 制 ， 主 要 接口 如 下 : 





获取 指定 的 自 旋 锁 。 
禁止 本 地 中 断 并 获取 指定 的 锁 。 


spin_lock 








spin_lock_irq 





spin_lock_irqsave 





释放 指定 的 锁 。 


spin_unlock 
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保存 本 地 中 断 的 当前 状态 ,禁止 本 地 中 断 ,并 获取 指定 的 锁 。 





释放 指定 的 锁 ,并 激活 本 地 中 断 。 

spin_unlock_irqstore 释放 指定 的 锁 , 并 让 本 地 中 断 恢 复 到 以 前 状态 。 
动态 初始 化 指定 的 spinlock_t。 

试图 获取 指定 的 锁 , 如 果 未 获取 , 则 返回 0。 

如 果 指 定 的 锁 当 前 正在 被 获取 , 则 返回 非 0, 否 则 返回 0。 


spin, unlock, irq 








spin lock init 





spin, trylock 





spin, is. locked 

对 不 同 进程 上 下 文 之 间 的 数据 访问 保护 ， 为 了 保证 性 能 ，Linux 内 核 根 据 读 写 操作 的 频 

繁 程度 不 同 提供 了 各 种 锁 机 制 ， 如 读 写 锁 、RCU 等 〈 主 要 应 用 于 文件 系统 和 网 络 部 分 ) 。 但 
是 驱动 开发 等 最 常 使 用 的 还 是 mutex (HJF) 操作 ， 相 应 的 操作 接口 如 下 : 








初始 化 互 斥 量 。 
检查 互 斥 量 是 否 被 锁定 。 
获取 互 斥 量 。 
释放 互 斥 量 。 
释放 W/W AR Eo 
mutex_lock_interruptible 获取 互 斥 量 可 以 被 信号 中 断 。 
尝试 非 阻塞 获取 互 斥 量 。 
原子 减 操作 , 当 为 0 时 获得 互 斥 量 。 





mutex_init 








mutex_is_ locked 





mutex_lock 








mutex_unlock 





ww_mutex_unlock 














mutex_trylock 





atomic_dec_and_mutex_lock 


这 两 种 锁 的 使 用 方法 见 表 3-1。 
表 3-1 自 旋 锁 和 互 斥 使 用 方法 



























































需 求 建议 的 加 锁 方法 
低 开销 加 锁 优先 使 用 自 旋 锁 
短期 锁定 优先 使 用 自 旋 锁 
长 期 加 锁 优先 使 用 互 斥 体 
中 断 上 下 文中 加 锁 使 用 自 旋 锁 并 要 关中 断 
持 有 锁 并 需要 睡眠 使 用 互 斥 体 

















内 核 中 的 情况 很 复杂 ， 保 护 数据 的 互 斥 及 一 致 性 操作 也 有 很 多 种 ， 以 上 只 是 简单 介绍 了 
两 种 ， 后 面 会 有 更 详细 的 介绍 。 


3.5.5 抢占 和 屏障 


从 2.6 版 本 之 后 的 内 核 已 经 是 抢占 式 内 核 ， 也 就 是 说 在 内 核 态 就 可 以 实现 抢占 。 这 对 内 
核 来 说 是 质 的 飞跃 ， 可 以 提升 系统 实时 性 与 整个 系统 的 效率 ， 同 时 也 给 系统 开发 增加 了 难 
度 。 茶 些 特殊 情况 需要 禁止 和 使 能 内 核 抢占 。 

其 实 使 用 自 旋 锁 已 经 可 以 防止 内 核 抢 占 了 ,但 是 有 时 候 仅 仪 需要 禁止 内 核 抢 占 ， 不 需要 
像 自 旋 锁 那样 消耗 大 的 锁 。 这 时 候 就 需要 使 用 禁止 内 核 抢占 的 方法 ， 具 体 如 下 : 





增加 抢占 计数 ， 从 而 禁止 内 核 抢 占 。 

减少 抢占 计数 ， 并 当 该 值 降 为 0 时 检查 和 执行 被 挂 起 的 需 调 度 的 任务 。 
preempt_enable_no_resched 激活 内 核 抢占 但 不 再 检查 任何 被 挂 起 的 需 调 度 的 任务 。 
返回 抢占 计数 。 





preempt_disable 








preempt_enable 

















preempt_count 
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BE BORA AIR, BPE AE a eT CSET IR OE, BLU eb areas n] VAPETTRL 
序 执行 。 一 段 代码 由 于 编译 器 或 者 处 理 器 在 编译 和 执行 时 对 执行 顺序 进行 优化 ,会 使 代码 的 
执行 顺序 和 所 写 的 代码 有 区 别 。 一 般 情 况 下 ， 这 没有 什么 问题 ， 但 是 在 并 发 条 件 下 ， 可 能 会 
出 现 取得 的 值 与 预期 不 一 致 的 情况 。 在 某 些 并 发 情况 下 ， 为 了 保证 代码 的 执行 顺序 ， 引 入 了 
一 系列 屏障 方法 来 阻止 编译 器 和 处 理 器 的 优化 ， 具 体 方法 如 下 : 


rmb 一 一 阻止 跨越 屏障 的 载 人 动作 发 生 重 排序 。 

read. barrier depends 阻止 跨越 屏障 的 具有 数据 依赖 关系 的 载 入 动作 重 排序 。 

wmb 一 一 阻止 跨越 屏障 的 存储 动作 发 生 重 排序 。 

mb 一 一 阻止 跨越 屏障 的 载 人 和 存储 动作 重新 排序 。 

smp_rmb 一 一 在 SMP 上 提供 rmb( ) 功 能 , 在 UP 上 提供 barrier( ) 功 能 。 

在 SMP 上 提供 read_barrier_depends( ) 功 能 , 在 UP 上 提供 barrier( ) 功 能 。 
smp_wmb 一 一 在 SMP 上 提供 wmb( ) 功 能 , 在 UP 上 提供 barrier( ) 功 能 。 

smp_mb 一 一 在 SMP 上 提供 mb( ) 功 能 , 在 UP 上 提供 barrier( ) WHE. 

阻止 编译 器 跨越 屏障 对 载 入 或 存储 操作 进行 优化 。 




















smp_read_barrier_depends 








barrier 


3.6 小 结 


本 章 首 先 对 Linux 内 核 框 架 进 行 层 次 分 析 ， 然 后 从 需求 的 角度 探讨 Linux 内 核 的 功能 
设备 分 类 ， 接着 探讨 Linux 内 核 需要 解决 的 无 关 性 问题 以 及 实现 方法 ， 最 后 介绍 Linux 内 核 
提供 的 基本 库 功 能 。 

Linux 内 核 是 不 断 发 展 的 ， 也 是 不 断 变化 的 ， 具 体 都 是 为 了 适应 需求 的 变化 。 对 Linux 
内 核 的 学 习 和 研究 要 从 需求 的 角度 出 发 ， 采 用 层次 化 分 析 的 方法 ， 重 点 关注 其 采用 何 种 设计 
模式 解决 问题 ， 并 要 细 化 到 具体 的 API， 这 样 才能 从 整体 到 细节 把 握 好 Linux 内 核 开 发 ， 成 
为 Linux 内 核 和 驱动 开发 达 人 。 
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第 4 章 ”内核 核心 介绍 及 硬件 的 具体 实现 


关于 Linux 内 核 核心 ,第 3 章 已 经 简单 分 析 了 需求 和 功能 ， 接 下 来 就 对 Linux 内 核 核心 
各 个 部 分 进行 详细 的 介绍 和 分 析 。 主 要 集中 在 芯片 相关 的 功能 模块 的 介绍 和 分 析 。 在 层次 上 
本 章 的 内 容 属 于 人 硬件 接口 屋 、 逻 辑 层 等 底层 的 功能 模块 。 详 细 了 解 相 关内 容 对 芯片 移植 相关 
的 工作 会 有 很 大 的 帮助 。 


4.1 内 核 初始 化 


初始 化 是 进入 系统 首先 执行 的 部 分 ， 可 以 说 是 系统 的 和 人口， 其 中 会 涉及 系统 中 各 个 模块 
的 初始 化 ， 对 内 核 来 说 也 不 例外 。 内 核 的 初始 化 不 同 于 其 他 系统 ， 有 其 自身 的 特殊 性 ， 比 如 
和 处 理 器 相关 性 比较 大 ， 关 系 到 整个 系统 的 正常 运行 等 。 注 意 : Linux 内 核 初始 化 ， 不 仅 要 
使 硬件 和 其 自身 进入 正确 的 执行 状态 ， 还 要 使 得 应 用 系统 进入 合适 的 状态 。 从 这 些 角度 看 理 
解 初始 化 对 了 解 Linux 内 核 及 整个 系统 有 十 分 重要 的 意义 。 


4.1.1 内 核 初始 化 的 基本 需求 


Linux 系统 中 内 核 处 于 硬件 和 应 用 层 之 间 。 整 个 系统 启动 和 初始 化 的 过 程 ，Linux 内 核 是 
在 主 处理 需 启动 之 后 才 会 执行 。 不 同 的 处 理 需 启动 流程 并 不 相同 ， 这 就 要 求 Linux 内 核能 文 
持 各 种 处 理 器 的 初始 化 操作 。Linux 内 核 各 个 模块 ， 大 部 分 设计 时 做 到 了 体系 结构 无 关 。 这 
就 要 求 在 初始 化 过 程 中 要 将 体系 结构 相关 和 无 关 部 分 分 开 。 另 外 同一 体系 结构 ， 由 于 外 设 的 
不 同 也 会 有 板 级 的 差别 ， 在 初始 化 的 框架 中 也 要 考虑 板 级 的 接口 。 内 核 相 关 的 初始 化 既 要 有 
体系 结构 相关 的 部 分 ， 又 要 有 板 级 相关 的 部 分 。 

Linux 内 核 是 一 个 庞大 的 系统 ， 最 终生 成 的 操作 系统 代码 的 执行 文件 非常 大 。 如 果 直 接 
使 用 执行 文件 ， 就 要 求 外 部 存储 保留 很 大 的 空间 用 于 存放 操作 系统 的 执行 镜像 。 启 动 过 程 读 
取 执 行 镜像 文件 比较 长 ， 这 对 于 系统 使 用 来 说 是 不 经 济 的 。 考 虑 到 系统 在 内 存 中 执行 速度 会 
很 快 ， 而 启动 时 如 果 将 比较 小 的 压缩 文件 读 入 内 存 ， 然 后 解压 ， 这 样 就 会 节省 外 部 存储 的 空 
间 。 另 外 现在 的 处 理 器 从 内 存 解压 比 从 外 部 存储 读 取 速度 快 得 多 ， 所 以 通常 在 内 存 中 解压 启 
动 也 会 快 ， 这 就 需要 Linux 内 核 初始 化 的 时 候 ， 能 够 将 压缩 的 image 进行 解压 ， 当 然 解 压 功 
能 应 该 由 Linux 内 核 提 供 。 

普通 应 用 一 般 都 是 有 初始 化 参数 的 ， 当 然 内 核 同 样 需要 有 初始 化 参数 。 内 核 中 各 个 模块 
也 有 这 种 需求 ， 这 就 要 求 内 核能 提供 一 种 方式 进行 初始 化 参数 设置 ， 并 且 能 标定 不 同 模块 的 
初始 化 参数 ， 还 要 将 初始 化 参数 传 给 对 应 的 模块 。 

还 有 一 个 需求 是 和 内 存 占用 相关 的 ， 通 常 初始 化 代码 只 在 初始 化 的 时 候 执行 ， 而 在 系统 
的 运行 过 程 中 并 不 需要 ， 这 样 在 系统 初始 化 之 后 就 应 该 把 这 部 分 内 存 释 放 以 减少 这 部 分 内 存 
资源 的 无 故 浪费 。 
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4.1.2 内 核 初 始 化 框架 介绍 


谈 到 内 核 初始 化 ， 首 先 要 考虑 到 处 理 器 的 初始 化 过 程 。 处 理 器 上 电 后 ， 内 存 (可 以 执 
行 代 码 的 设备 ) 还 没有 初始 化 、 没 有 处 于 正常 的 工作 状态 ， 也 就 不 能 直接 执行 代码 。 对 于 
该 问题 ， 各 种 体系 结构 都 会 规定 上 电 重 启 (通常 为 power on reset) 的 情况 下 ， 处 理 器 执行 
第 一 条 指令 的 地 址 ， 而 具体 的 处 理 器 厂商 就 将 可 执行 代码 存放 在 该 地 址 处 ， 使 得 处 理 器 上 电 
后 能 正常 运行 ， 通 常 这 部 分 代码 被 叫做 ROM Code。 处 理 器 首先 执行 ROM Code 的 代码 ， 处 
理 右 中 还 有 一 部 分 存储 空间 即 内 部 SRAM 可 以 执行 代码 ,但 是 SRAM 通常 都 比较 小 ， 不 能 
放下 Linux 内 核 的 压缩 image, ， 这 样 就 需要 有 个 中 间 过 渡 的 模块 ， 该 模块 的 主要 功能 是 进行 
系统 加 载 ， 叫 做 boot loader。 当 然 根据 具体 的 情况 ，boot loader 也 可 以 分 级 ， 最 终 boot loader 
会 加 载 Linux 内 核 的 压缩 image， 并 将 参数 传 给 Linux 内 核 ， 跳 转 到 Linux 内 核 中 让 其 自身 初 
始 化 并 执行 。 这 个 阶段 的 流程 如 图 4-1 所 示 。 


Power/clock/reset Boot ROM Boot loader 


Preinitialization OS/application 


Ramp sequence (OS independent) (OS independent) 





图 4-1 处 理 器 启动 流程 


图 4-1 引 自 《DM 3730 芯片 手册 》 中 第 3524 页 的 流程 图 ， 虽 然 是 DM 3730 芯片 手册 中 
的 图 ， 但 是 该 流程 广泛 适用 于 各 种 处 理 器 。 

Rom Code 通常 是 由 处 理 器 厂商 进行 开发 ， 而 所 谓 的 软件 初始 化 是 从 boot loader 开始 的 。 
整个 软件 系统 初始 化 流程 如 图 4-2 所 示 。 


Bootloader 
Low level hardware "n 
initialization init process 
System initialization 
from userspace 


Fetch and copy 
Linux kernel 
to RAM 





图 4-2 系统 初始 化 流程 


由 图 4-2 可 见 ，boot loader 的 主要 工作 包括 两 部 分 : 其 一 ， 进 行 一 些 硬件 的 初始 化 ， 如 
内 存 以 及 一 些 必 要 设备 的 初始 化 ; 另外 ，boot loader 还 要 获得 Linux 内 核 image 并 将 其 复制 
到 内 存 中 。 但 是 注意 boot loader 能 使 用 的 资源 比较 有 限 ， 所 以 功能 比较 简单 。 内 核 初始 化 的 
主要 任务 则 是 加 载 并 执行 应 用 空间 的 初始 化 程序 ， 由 系统 应 用 接管 系统 完成 特定 的 功能 ， 而 
Linux 内 核 则 开始 为 应 用 提供 良好 的 服务 。 
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Linux 内 核 初始 化 框架 如 图 4-3 所 示 。 
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图 4-3 Linux 内 核 初 始 化 框架 


图 4-3 展示 了 Linux 内 核 的 初始 化 的 基本 流程 ， 首 先是 与 体系 结构 相关 的 head. o 部 分 ， 
然后 跳 入 体系 结构 无 关 的 代码 start_ kernel (这 里 已 经 进入 虚拟 地 址 执行 ) ， 开 始 内 核 后 续 
的 初始 化 处 理 。 其 中 会 涉及 很 多 模块 的 初始 化 ， 当 然 有 些 模 抉 中 包含 体系 结构 相关 以 及 板 级 
相关 的 初始 化 操作 。 最 终 Linux 内 核 会 执行 应 用 系统 的 初始 化 进程 init process， 从 而 真正 地 
转 入 应 用 系统 中 ， 开 始 各 种 各 样 应 用 的 操作 。 


4.1.3 TI 心 片 内 核 初始 化 相关 实现 详解 


下 面 以 4.1.1 节 所 介绍 的 系统 初始 化 流程 为 例 ， 来 看 看 不 同 的 处 理 器 启动 流程 的 区 别 。 
图 4-4 和 图 4-5 分 别 是 DM 816X 和 DM 3730 的 启动 流程 。 

从 图 4-4 和 图 4-5 可 见 ，DM 816X 和 DM 3730 启动 流程 还 是 有 区 别 的 。 主 要 区 别 在 于 : 
DM 816X 的 boot loader 阶段 只 是 u — boot, Mi DM 3730 的 boot loader 阶段 则 分 为 x — loader 和 
u 一 boot。 其 中 原因 是 芯片 内 部 片 内 内 存 大 小 。DM 3730 中 只 有 64 KB 的 片 内 内 存 ， 而 DM 
816X 有 512KB， 这 样 DM 816X 就 可 以 直接 将 u — boot 的 image 放 入 片 内 内 存 中 ， 而 DM 3730 
的 片 内 内 存 空 间 不 够 ， 就 需要 通过 一 个 mini boot loader 来 过 渡 。 可 见 资源 对 于 系统 的 设计 还 
是 有 很 大 影响 的 。 

接 下 来 以 TI 芯片 为 基础 进行 整个 系统 的 初始 化 过 程 详解 。 从 这 个 过 程 中 可 以 了 解 到 系 
统 移植 的 信息 。 

1. image 文件 生成 

Linux 内 核 的 编译 过 程 ， 首 先 会 将 各 个 模块 单独 编译 ， 然 后 链接 并 最 终生 成 一 个 很 大 的 
文件 ， 这 个 文件 就 是 vmlinux。 其 中 当然 包括 初始 化 的 代码 ， 而 整个 Linux 系统 的 起 始 地 址 
这 一 重要 信息 在 vmlinux. lds 内 (此 文件 是 体系 结构 相关 的 )。 以 ARM 为 例 ， 该 文件 是 由 
arch/arm/kernel/vmlinux. Ids. S 在 编译 链接 时 生成 。 下 面 先 看 看 DM 3730 编译 链接 生成 的 该 
文件 的 部 分 内 容 。 
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图 4-4 DM 816X 启动 流程 
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u-boot. 
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- Boot-loader 
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Al4-5 DM 3730 启动 流程 


OUTPUT_ARCH ( arm) 
ENTRY ( stext ) 
jiffies = jiffies 64; 
SECTIONS 
| 
. =0xC0000000 + 0x00008000 ; 
. init : | / * Init code and data * / 
_stext =. ; 
_sinittext =. ; 
* (. head. text) 
* (. init. text) ** (. epuinit. text) * (. meminit. text) 
_einittext =. ; 
__proc_info_begin =. ; * (. proc. info. init) __proc_info_end =. ; 
__arch_info_begin =. ; 
* (. arch. info. init) 
. arch, info. end =. ; 
. tagtable begin =. ; 
* (. taglist. init) 
. tagtable end =. ; 
. =ALIGN(16) ;. setup. start =. ; * (. init. setup) _ setup end =. ; 
. initeall _ start = . ; * (. initcallearly. init) __ early, initeall, end — .; * (. initcall0. init) * 
(. initeallOs. init) * (. initealll. init) * (. initeallls. init) * (.initcall2. init) * (. initcall2s. init) * 
(. initeall3. init) * (. initeall3s. init) * (. initcall4. init) * (. initcall4s. init) * (.initcall5. init) * 
(. initeall5s. init) * (. initcallrootfs. init) * (. initcall6. init) * (. initcall6s. init) * (. initcall7. init) 
* (. initeall7s. init) __initcall_end =. ; 
__con_initcall_start =. ; * (. con, initcall init) | con, initcall end =. ; 
. security initcall start =. ; * (. security, initcall. init) __security_initcall_end =. ; 
. =ALIGN(4) ;. initramfs start =. ; * (. init. ramfs) . = ALIGN(8) ; * (. init. ramfs. info) 
. init, begin = | stext ; 
* (. init. data) * (. cpuinit. data) * (. meminit. data) . =ALIGN(8) ;. ctors start =. ; * (. ctors) 


. etors end =. ; * (. init. rodata) . = ALIGN(8) ;. start, mcount, loc =. ; * (. mcount loc) _ stop 





mcount, loe =. ; * (. cpuinit rodata) * (. meminit. rodata) 


} 
. = ALIGN( (1 «& 12) ) ;. data. . perepu : AT( ADDR (. data. . percpu) -0) | __per_cpu_load =. ;__per_ 


cpu. start =. ; * (. data. . percpu. . first) . = ALIGN ( (1 << 12)); * (. data. . percpu. . page. aligned) * 
(. data. . percpu. . readmostly) * (. data. . percpu) * (. data. . percpu. . shared aligned) __per_cpu_end =. ;| 
. =ALIGN( (1 <12) ); 


__init_end =. ; 








从 这 部 分 链接 脚本 可 见 Linux 内 核 的 起 始 位 置 是 0xC0008000 ， 这 个 地 址 可 以 保证 整个 系 
统 转 和 人 虚拟 地 址 后 ， 内 核 代 码 的 地 址 映射 仍然 是 一 致 的 。0xC0008000 的 位 置 是 通过 如 下 vm- 
linux. lds. S 语句 生成 的 。 注 意 通常 CONFIG_XIP_KERNEL 都 是 不 被 配置 的 ， 另 外 宏 PAGE 
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OFFSET 和 TEXT_OFFSET 都 是 和 体系 结构 相关 的 。 一 般 的 PAGE_OFFSET Æ 0x80000000 , 而 
TEXT. OFFSET 是 0x8000 , 


#ifdef CONFIG. XIP KERNEL 

. =XIP_ VIRT ADDR(CONFIG XIP PHYS ADDR) ; 
#else 

. PAGE OFFSET + TEXT OFFSET; 
#endif 


另外 从 生成 的 链接 脚本 可 见 ， 除 了 具体 的 处 理 器 和 体系 结构 信息 (如 . proc. info. init ) 
外 ， 还 有 一 些 init 的 信息 (主要 是 各 种 init 的 段 ) ， 这 些 信 息 还 是 很 重要 的 。 之 前 讨论 内 核 
初始 化 需求 的 时 候 ， 提 到 初始 化 代码 应 该 在 初始 化 之 后 释放 相应 的 内 存 空间 ， 这 里 可 以 看 出 
Linux 内 核 已 经 将 初始 化 相关 的 代码 统一 存放 并 管理 ， 一 方面 方便 初始 化 时 调用 ， 另 一 方面 
可 以 在 系统 初始 化 之 后 将 这 部 分 空间 释放 。 这 个 文件 还 是 很 重要 的 ， 一 个 文件 就 解决 了 几 个 
问题 。 

内 核 生成 的 vmlinux 文件 实在 太 大 、 不 适合 引导 加 载 ， 所 以 需要 进行 压缩 ，Linux 内 核 
压缩 后 为 zzmage， 可 以 说 zimage 是 将 可 执行 Linux 内 核 vmlinux 压缩 后 作为 数据 包含 在 自身 
中 ， 图 4-6 展示 了 vmlinux 到 zImage 的 生成 流程 。 

objcopy gzip as Id objcopy 


piggy.gzip.S 


piggy.gzip.o 
piggy.gz 
vmlinux 





















vmlinux 


Stripped Compressed 
kernel kernel 
*Kernel proper" binary binary 
Raw kernel (binary 
executable object) 
(ELF object) ; 
(in arch/<arch> Kernel image 
boot/compressed) For bootloader 
Details f ili (binary object) 
etails found by compiling asm wrapper Composite 
with make V=1 round kernel image 
piggy.gzip.gz (ELF object) 
+ bootstrap 
code 





Al 4-6  zlmage 生成 流程 





zlmage 的 生成 过 程 有 一 个 问题 ， 就 是 zmage 究竟 放 在 哪里 ，zImage 需要 知道 这 个 位 置 。 
因为 它 不 能 对 这 个 位 置 进行 任何 的 假设 ,并 且 需 要 该 位 置信 息 来 判断 解压 后 的 空间 是 否 会 对 
自身 有 影响 。 另 外 对 于 具体 的 memory 空间 ， 地 址 信息 是 和 具体 处 理 器 相关 的 ， 需 要 一 个 方 
式 让 与 体系 结构 相关 的 zImage 中 包含 这 些 信息 ， 这 样 就 可 以 自给 自足 了 。 下 面 看 看 Linux 内 
核 是 如 何 实现 的 。 

从 图 4-6 中 可 见 ， 压 缩 后 的 vmlinux 会 增加 arch/arm/boot/compressed 的 代码 作为 头 ， 然 
后 生成 xmage， 先 来 看 看 zlmage 头 中 head. S 的 代码 ， 这 里 只 是 摘录 了 一 部 分 : 
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start ; 
. typestart , function 
THUMB( adrrl2, BSYM( 1f) ) 
THUMB( bxr12 ) 
THUMB( . rept6 ) 
ARM( . rept8 ) 


movrO , 10 
. endr 
blf 
. word 0x016f2818 @ Magic numbers to help the loader 
. word start @ absolute load/run zImage address 
. word  edata @ zlmage end address 
1: movr7, rl @ save architecture ID 
movr8 , 12 @ save atags pointer 


#ifdef CONFIG_AUTO_ZRELADDR 
@ determine final kernel image address 
mov 14, pe 
and r4, r4, #0xf8000000 
add r4, r4, #TEXT_OFFSET 
#else 
ldr r4, = zreladdr 
#endif 
subs 10, 10, rl @ calculate the delta offset 


这 部 分 代码 会 保存 处 理 器 架构 ID 信息 和 atags 信息 (用 于 传送 启动 参数 等 信息 )。 男 外 


有 个 符号 zreladdr， 该 符号 就 是 zmage 最 终 被 加 载 到 内 存 中 的 地 址 。 这 个 符号 在 哪里 生成 的 
呢 ? HAA compressed 目录 下 的 Makefile 文件 ， 其 中 有 这 人 么 一 段 : 








# Supply ZRELADDR to the decompressor via a linker symbol. 
ifneq ( $ (CONFIG_AUTO_ZRELADDR) ,y) 

LDFLACS vmlinux := -- defsym zreladdr = $ (ZRELADDR) 
endif 











这 里 直接 通过 链接 工具 创建 符号 zreladdr， 但 数据 是 通过 ZRELADDR 参数 传递 的 。 这 个 
参数 又 是 如 何 来 的 呢 ? 继续 追踪 boot 目录 下 的 Makefile: 





ifneq ( $ (MACHINE), ) 
include $ (srctree)/ $ (MACHINE) /Makefile. boot 
endif 


# Note: the following conditions must always be true: 
# ZRELADDR == virt_to_phys( PAGE OFFSET + TEXT. OFFSET) 
# PARAMS PHYS must be within 4MB of ZRELADDR 


$1 


# INITRD PHYS must be in RAM 
ZRELADDR := $ (zreladdr - y) 
PARAMS PHYS := $ (params phys - y) 
INITRD_PHYS := $ (initrd_phys -y) 


export ZRELADDR INITRD_PHYS PARAMS_PHYS 


这 里 可 以 看 到 ZRELADDR 是 由 zreladdr -y 定义 的 ， 又 出 来 一 个 变量 。 为 什么 不 直接 定 
义 呢 ? 这 样 设计 是 为 什么 呢 ? 之 前 提 到 内 存 地 址 在 具体 的 处 理 器 之 间 是 有 差别 的 ， 如 何 屏蔽 
这 种 差别 ?这 种 差别 的 配置 还 是 要 放 入 具体 的 处 理 器 代码 目录 中 。Linux 内 核 也 是 这 个 思路 ， 
这 段 代 码 的 开始 include 一 个 文件 Makefile. boot， 而 且 该 文件 是 在 一 个 具体 的 处 理 器 目录 中 
的 ， 就 是 它 进行 了 处 理 器 差异 的 配置 。 具 体 到 DM 3730 等 之 前 介绍 的 TI 处 理 右 都 是 引用 自 
mach - omap2 目录 下 的 Makefile. poot， 其 内 容 如 下 : 














zreladdr — y := 0x80008000 
params phys -y — :20x80000100 
initrd. phys — y := 0x80800000 


查看 一 下 芯片 手册 会 发 现 ， 第 一 段 内 存 的 地 址 空间 就 是 从 0x80000000 起 始 的 地 址 ， 这 
样 就 对 应 上 了 。 可 见 新 的 处 理 器 只 要 在 对 应 的 目录 中 定义 自己 的 Makefile. boot (其 中 包括 上 
面 的 定义 ) 就 能 自动 生成 正确 的 zImage。 

到 这 里 算是 告 一 段落 ， 但 是 能 入 式 开发 工程 师 通 常 比较 熟悉 ulmage， 为 什么 不 是 zImage 
WE? 这 个 和 mu - boot 的 Boot loader 功能 相关 ， 主 要 是 因为 zImage 知道 自 己 所 存放 的 地 址 ， 但 
是 它 还 是 需要 u- boot 将 其 放 入 合适 的 位 置 。u - boot 是 通过 ulmage 的 开始 一 段 的 内 容 知道 
这 个 信息 的 ， 也 就 是 说 ulmage 实际 是 给 zlmage 封装 了 一 个 简单 的 头 ， 这 个 头 中 包括 一 些 
u — boot 需要 的 信息 。 这 就 要 求 Linux 内 核能 直接 生成 umage。 来 看 看 umage 是 如 何 生成 的 ? 
同样 是 在 arch/arm/boot 目录 下 的 Makefile : 


























quiet cmd, uimage = UIMAGE $@ 
cmd uimage = $ (CONFIG. SHELL) $ (MKIMAGE) - A arm - O linux - T kernel V 
-C none- a $ (LOADADDR) -e $ (STARTADDR) \ 
-m Linux — $(KERNELRELEASE) -d $< $@ 


ifeq ( $ (CONFIG_ZBOOT_ROM) ,y) 

$ (obj) /ulmage; LOADADDR = $ ( CONFIG_ZBOOT_ROM_TEXT) 
else 

$ (obj)/ulmage: LOADADDR = $ (ZRELADDR) 

endif 


$ (obj)/ulmage: STARTADDR = $ (LOADADDR) 


$ ( obj) /ulmage: $ (obj)/zImage FORCE 
$ (call if_changed, uimage ) 
@echo ^ Image $ @ is ready 
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这 里 的 cmd_uimage 是 kbuild 用 来 定义 客户 自 定 义 的 编译 命令 ， 该 命令 的 名 字 就 是 
uimage， 实 际 调 用 u — boot 的 mkimage 命令 生成 umage。 在 DM 3730 等 TI 处 理 器 中 最 终 会 将 
ZRELADDR B} 0x80008000 作为 参数 传人 ， 这 样 就 正确 地 生成 umage， 完 成 了 Linux 内 核 im- 
age 生成 的 全 过 程 。 

2. 处 理 器 启动 至 boot loader 

先 来 看 看 芯片 的 启动 时 序 ， 以 DM 3730 为 例 ， 上 电 时 序 如 图 4-7 所 示 。 


Signal color-coding 
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图 4-7 DM 3730 上 电 时 序 
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图 4-7 引 自 《DM 3730 芯片 手册 》 中 第 266 页 框图 。 从 该 图 中 可 以 看 到 整个 芯片 上 电 的 硬 
件 信号 流程 ， 这 对 了 解 整 个 系统 的 正常 启动 至 关 重 要 。 男 外 可 以 看 出 系统 的 启动 是 从 外 部 的 供 
电 和 时 钟 信号 开始 ， 以 主 处理 器 的 复位 信号 (MPU_RST) 信号 拉 高 为 结束 ， 之 后 就 开始 执行 
启动 代码 了 。 硬 件 启动 时 序 正常 的 重要 因素 就 是 保证 供电 和 时 钟 的 稳定 ， 要 符合 芯片 的 参数 
要 求 。 

处 理 器 上 电 启 动 代码 的 执行 是 和 体系 结构 相关 的 ， 以 ARM 为 核心 的 处 理 器 ， 上 电 启 动 
执行 的 第 一 个 代码 是 reset 向 量 的 代码 reset 向 量 上 电 默 认为 0x00000000 地 址 。 指 令 执 行 需 
要 XIP 存储 器 ,除了 ROM、RAM 之 外 ，NOR Flash 也 是 XIP 存储 器 ， 所 以 处 理 器 是 可 以 从 
NOR 启动 的 。 不 同 的 处 理 器 如 何 选择 启动 指令 执行 ， 比 如 转 到 ROM Code 执行 ， 就 各 有 各 
的 实现 方式 。 下 面 是 《DM 3730 芯片 手册 》 中 第 203 页 的 一 段 话 : 

The system has a 1 - MB boot space in the on - chip boot ROM or on the CPMC memory 


























space. When booting from the on — chip ROM with the appropriate external sys. boot5 pin configura- 
tion, the 1- MB memory space is redirected to the on - chip boot ROM memory address space [ 0x4000 
0000 - Ox400F FFFF]. When booting from the GPMC with the appropriate external sys, boot5 pin 
configuration, the memory space is part of the CPMC memory space. For more information about sys 
boot5 pin configuration, see Chapter 10, Memory Subsystem, and Chapter 26, Initialization. 

根据 这 段 话 可 以 明确 DM 3730 芯片 设计 时 是 如 何 解决 该 问题 的 。DM 3730 在 系统 启动 
时 将 0x0 开始 的 1MB 空间 直接 映射 到 ROM Code 中 ， 当 启动 时 检查 sys_boot5 引 脚 来 决定 地 
址 是 否 重 定向 ， 然 后 再 reset ARM 核心 ， 这 样 使 得 ARM 可 以 执行 正确 的 代码 来 进行 启动 。 

系统 启动 后 ，ARM 就 开始 执行 ROM Code 的 代码 。ROM Code 支持 的 启动 设备 称 为 启动 
能 力 ， 具体 的 启动 能 力 是 不 同 的 处 理 融 根据 需求 实现 的 。 图 4-8 和 图 4-9 分 别 是 DM 816X 
和 DM 3730 的 ROM Code 框架 。 
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图 4-8 DM 816X 芯片 ROM Code 框架 
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图 4-9 DM 3730 its Fr ROM Code 框架 








从 图 4-8 和 图 4-9 Pay UL, DM 816X 的 启动 能 力 要 比 DM 3730 强 得 多 。DM 816X xc 
持 网 络 启动 和 PCIe 启动 ， 这 些 都 是 DM 3730 不 具备 的 ， 也 是 符合 DM 816X 服务 器 以 及 
PCle 板 卡 这 些 功能 需求 的 。 注 意 DM 3730 中 的 ROM Code 有 clock detection 模块 ， 主 要 用 
来 检测 外 部 高 速 晶 振 的 频率 。 通 常 ROM Code 运行 时 ， 主 处 理 器 的 时 钟 频率 为 外 部 高 速 晶 
振 的 频率 (如 26 MHz) 。 这 里 ROM Code 的 检测 模块 确认 时 钟 频率 ， 可 以 为 后 续 boot load- 
er 以 及 Linux 内 核 设 置 各 个 不 同 模块 的 时 钟 提供 基础 时 钟 ， 进 而 明确 如 何 进行 配置 才能 得 
到 需要 的 时 钟 频 率 。 

ROM Code 的 主要 任务 就 是 到 其 支持 的 设备 中 查找 boot loader， 并 加 载 到 片 内 RAM 中 执 
行 。 这 个 过 程 中 涉及 两 部 分 : 

其 一 ， 识 别 正确 的 boot loader 并 加 载 ， 通 常 ROM Code 会 通过 image 增加 特定 的 头 标记 ， 
来 识别 并 正确 加 载 。 芯 片 厂商 会 提供 相应 的 生成 和 烧 写 工具 代码 以 供 使 用 。 

其 二 ，boot loader 编译 的 时 候 还 是 要 以 片 内 RAM 的 地 址 空间 为 基础 ， 这 就 要 在 boot 
loader 中 进行 设置 。 

先 看 看 DM 3730 是 如 何 操作 的 。 

x - loader 需要 在 片 内 内 存 中 执行 ， 其 板 级 相关 代码 对 应 的 目录 中 有 config. mk 文件 ， 其 
中 会 设置 代码 的 起 始 地 址 : 























TEXT_BASE = 0x40208800 


而 在 链接 的 时 候 会 通过 参数 - Ttext $ (TEXT_BASE) 指定 代码 的 起 始 地 址 为 TEXT_ 
BASE 定义 的 地 址 。 这 样 整 个 代码 就 是 在 片 内 内 存 空间 。x - loader 加载 到 片 内 RAM 后 其 内 
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存 布局 如 图 4-10 所 示 。 
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K] 4-10 DM 3730 x - loader 执行 片 内 RAM 布局 


x - loader 的 最 终 image 要 加 入 特殊 的 头 信息 ， 上 有 具体 说 明 如 图 4-11 所 示 ， 图 4-11 518 
(DM 3730 芯片 手册 》。 其 中 包含 加 载 的 地 址 和 image 的 大 小 信息 。 
Table 26-46. GP Device Software Image 














Field Non-XIP Device XIP Device Size (Bytes) Description 
Offset Offset 

Size Ox0000 一 4 Size of the image 

Destination Ox0004 - 4 Address where to store the image 

Image Ox0008 Ox0000 x Image 





Kl 4-11 DM 3730 x - loader image 头 信 息 说 明 
这 个 头 信 息 是 通过 工具 signGP 生成 的 ， 相 应 信息 如 下 : 


x — load. bin. ift; signGP System. map x — load. bin 
TEXT BASE = grep — w . start System. mapleut - d'. — fT 
. /signGP x — load. bin $ ( TEXT. BASE) 
cp x — load. bin. ift MLO 


MILB) TEXT | BASE， 这 就 要 求 加 载 的 地 址 和 编译 的 地 址 一 一 对 应 。 
u - boot 则 是 在 内 存 中 执行 ， 其 地 址 应 该 是 从 0x80000000 开始 的 空间 。u - boot 中 对 应 
的 config. mk 的 设置 : 


TEXT_BASE = 0x80e80000 


可 见 其 设置 在 内 存 的 地 址 空间 。 这 样 代 码 所 在 空间 的 问题 就 解决 了 。 但 又 出 现 一 个 问 
题 ， 代 码 被 加 载 到 什么 地 址 了 呢 ? 对 于 x - loader， 这 个 问题 没 办 法 回答 ， 原 因 在 于 ROM 
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Code 并 不 公开 这 些 信 息 。u — boot 则 是 通过 x - loader 加 载 的 ,来 看 看 相应 的 设置 ， 在 相应 的 
板 级 配置 文件 中 包含 如 下 的 信息 s 





#define CFG_LOADADDR 0x80008000 





这 个 就 是 加 载 的 地 址 ， 为 什么 和 代码 的 地 址 不 同 呢 ? 这 个 就 无 从 考究 了 。 这 种 不 同 
会 有 问题 吗 ? 答案 是 不 会 的 ， 主 要 是 因为 在 跳 转 到 加 载 地 址 执行 代码 (开始 处 为 汇编 代 
码 )， 是 使 用 的 是 相对 地 址 即 地 址 无 关 来 执行 ， 而 一 般 跳 转 指令 (如 b、bl 等 ) 都 是 相对 
地 址 跳 转 ， 所 以 没有 问题 。 但 是 如 果 u — boot 中 跳 转 到 start_armboot, 该 C 函数 使 用 的 是 
ldr pc 直接 加 载 指 令 寄存 器 这 种 绝对 地 址 跳 转 方式 ， 此 时 代码 的 地 址 必须 一 一 对 应 ， 否 则 
这 个 跳 转 就 会 出 现 问题 。 至 于 为 什么 一 定 要 进行 这 个 绝对 跳 转 ， 因 为 这 是 开发 者 设置 的 ， 
只 有 开发 者 才 最 了 解 其 内 存 布局 。boot loader 会 留 出 该 接口 给 开发 者 设置 ， 这 样 才 能 保证 
后 续 的 内 核 加 载 等 操作 的 正确 进行 。 在 绝对 跳 转 之 前 ，u - boot 和 x — loader 的 start. S 中 都 
包含 的 搬移 代码 的 重 定向 功能 能 保证 代码 地 址 和 在 地 址 空间 中 的 位 置 一 一 对 应 。 相 应 的 
重 定向 代码 如 下 : 









































relocate ; /* relocate U — Boot to RAM */ 
adr 10, start / * 10 < current position of code * / 
ldr rl, TEXT BASE / * test if we run from flash or RAM */ 
cmp 10, rl / * don t reloc during debug * / 


beq stack setup 


ldr 12, | armboot. start 
ldr 13,  bss start 


sub 12, r3, 12 / * 12 < size of armboot * / 
add 12, 10, 12 / * 12 < source end address * / 

copy. loop: / * copy 32 bytes at a time * / 
ldmia 10!, |13-110j / * copy from source address [10] */ 
stmia rl!, {r3-rl0} / * copy to target address [rl | */ 
cmp 10, r2 / * until source end addreee [r2] */ 


ble copy_loop 


这 些 代码 主要 实现 将 代码 移动 到 TEXT_BASE 开始 的 地 址 ，x - loader 也 采用 同样 的 办 法 
解决 加 载 地 址 和 编译 链接 地 址 不 匹配 的 问题 。 需 要 注意 的 是 : 这 段 代 码 还 是 比较 简单 的 实 
现 ， 其 中 并 没有 考虑 一 些 特殊 情况 的 覆盖 问题 ( 比如 拷贝 过 程 中 的 局 部 覆盖 ) ， 所 以 加 载 代 
码 的 地 址 和 编译 链接 的 地 址 要 有 比较 大 的 间隔 ， 才 能 保证 正确 的 结果 。 

再 来 看 看 DM 816X 是 如 何 操作 的 。 

由 于 DM 816X 片 内 RAM 有 512 KB ， 完 全 可 以 加 载 并 执行 u - boot， 所 以 在 该 阶段 只 需 
要 一 次 boot loader, Mj boot loader 同样 是 加 载 到 片 内 RAM 中 执行 。 

DM 816X 由 ROM Code 加 载 的 image 的 格式 同 DM 3730 ， 具 体 见 《DM 816X 芯片 手册 》 
中 第 2400 页 的 说 明 。 在 生成 image 方面 ，DM 816X 与 DM 3730 不 同 ，DM 3730 使 用 的 是 单 
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独 的 signGP TH, mi DM 816X 使 用 的 是 u - boot 中 的 mkimage 工具 。 在 u - boot AY tools H 
录 下 可 以 看 到 tiimage 的 C 文件 ， 这 就 是 定义 了 TI 特殊 的 image 头 及 其 生成 方式 ， 用 于 生成 
符合 DM 816X SbF ATHY image 文件 。 生 成 代码 是 在 Makefile 文件 中 ， 上 有 具体 内容 如 下 : 


$ ( obj) u — boot. ti; $ (obj) u - boot. bin 
$ (obj) tools/mkimage — T tiimage V 
-e $(TI LOAD ADDR) -n $(TI DEVICE) -d $ < $ (obj) $ (TI IMAGE) 





该 命令 通过 mkimage 添加 必要 的 头 信息 ， 如 加 载 地 址 、 设 备 信息 ， 并 生成 TI_IMAGE 5E 
义 名 字 的 image。 

这 里 可 见 ， 除 了 TI IMAGE 之 外 ,还 有 TI_LOAD_ADDR 和 TI. DEVICE 两 个 变量 需要 明 
确 。 它 们 都 是 在 哪里 定义 的 呢 ? 这 些 信息 和 板 级 信息 相关 ， 还 记得 之 前 提 到 的 板 级 配置 文件 
config. mk 吧 ， 就 是 在 其 中 定义 的 ， 来 看 看 具体 内 容 : 











# Output image name. Used only in case of non - xip. For NOR boot u — boot. bin 
# could be used. 

TI. IMAGE = u — boot. noxip. bin 

# This will be used by mkimage extension to select header for image 
TI. DEVICE = ti81xx 

3t ROM code will load u — boot to this address 

TI. LOAD ADDR =0x40400000 

TEXT BASE - 0x80700000 

CROSS COMPILE := arm — none - linux — gnueabi 

LDSCRIPT .= board/ti/ti8168/u — boot. Ids 

# Over — ride the macros if supplied from the Makefile 

sinclude $ ( OBJTREE)/board/ $ ( BOARDDIR ) /config. tmp 





这 里 定义 了 板 级 特殊 的 变量 ， 其 中 image 的 加 载 地 址 是 0x40400000 ， 即 在 片 内 内 存 的 地 
址 区 域 中 。 这 里 TEXT BASE 是 在 0x80700000， 且 为 内 存 地 址 ， 这 又 如 何 操作 呢 ? 后 续 会 
进行 说 明 。 另 外 有 一 部 分 就 是 加 载 了 特别 的 配置 文件 config. tmp， 其 中 的 原因 又 是 什么 呢 ? 
主要 是 因为 DM 816X 支持 从 不 同 的 设备 启动 ， 就 要 有 不 同 的 u- boot 的 image， 其 中 会 有 一 
些 特殊 的 设置 ， 这 些 特 殊 的 设置 可 以 通过 config. tmp 将 这 些 变量 重 定义 来 实现 。 这 样 就 开放 
一 个 重 定义 的 接口 文件 来 实现 差异 化 。 

具体 的 设置 是 在 Makefile 中 通过 不 同 的 配置 实现 ， 具 体内 容 如 下 : 






































ti8168_evm_config\ 
ti8168_evm_config_nand\ 
ti8168_evm_config_nor\ 
ti8168_evm_config_spi\ 
ti8168_evm_config_sd\ 


ti8168_evm_min_ocmc \ 
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ti8168_evm_min_pcie_32\ 
ti8168_evm_min_pcie_64\ 
ti8168_evm_min_sd: unconfig 


@ mkdir -p $ (obj) include 





@ echo "#define CONFIG_TI81 XX" >> $ (obj) include/config. h 

@ echo "define CONFIG_TI816X" >> $ (obj) include/config. h 

@ if | " $ (findstring  nand, $ 9 )" | ;then V 
echo "#define CONFIG. SYS NO FLASH" >> $ (obj) include/config. h ; V 
echo "#define CONFIG_NAND_ENV" >> $ (obj) include/config. h ; V 
echo "Setting up TI8168 NAND build with ENV in NAND..." ;\ 

elif [ " $ (findstring _nor, $@)" | ;then \ 
echo " #define CONFIG_NOR" >> $ (obj) include/config. h ; V 
echo " #define CONFIG_NOR_BOOT" >> $ (obj) include/config. h ; V 
echo "Setting up TI8168 NOR build with ENV in NOR..." ;\ 

elif [ " $ (findstring spi, $@)" | ;then V 
echo "#define CONFIG. SYS NO FLASH" >> $ (obj) include/config. h ; V 
echo " #define CONFIG_SPI_ENV" >> $ (obj) include/config. h ; V 


echo "#define CONFIG_TI81XX_SPI_BOOT" >> $ (obj) include/config. h ; V 
echo "Setting up TI8168 SPI build with ENV in SPI..." ;\ 
elif [ " $ (findstring _min_sd, $ 9 )" ] ;then V 


echo "#define CONFIG. SYS NO FLASH" >> $ (obj) include/config. h ; V 
echo " #define CONFIG_SD_BOOT" >> $ (obj) include/config. h ; V 
echo " TI IMAGE =u - boot. min. sd" >> $ (obj)board/ti/ti8168/ config. tmp; 


echo "Setting up TI8168 SD boot minimal build..." ;V 
elif [ " $ (findstring | min, peie 32, $ 9 )" | ;then | 








echo " TEXT. BASE =0x80700000" >> $ (obj)board/ti/ti8168/ config. tmp; 
echo " define CONFIG. TISI6X, MIN, CONFIG" >> $ (obj) include/config. h ; 

echo "Setting up TI8168 minimal build for 1st stage..." ; 

echo " #define CONFIG. SPI. BOOT" >> $ (obj)include/config. h; \ 

echo " define CONFIG_TI81XX_PCIE_BOOT" >> $ (obj)include/config. h ; 

echo " #define CONFIG_SYS_NO_FLASH" >> $ (obj) include/ config. h ; V 

echo " #define CONFIG_TI81XX_SPI_BOOT" >> $ (obj) include/config. h ; V 

echo " #define CONFIG_TI81XX_PCIE_32" >> $ (obj) include/config. h ; V 

echo " TI IMAGE =u - boot. min" >> $ (obj) board/ti/ti8168/ config. tmp; 

elif [ " $ (findstring _min_pcie_64, $@)" | ;then | 

echo " TEXT. BASE =0x80700000" >> $ (obj) board/ti/ti8168/config. tmp; \ 
echo " define CONFIG. TISI6X, MIN, CONFIG" >> $ (obj) include/config. h ; 

echo "Setting up TI8168 minimal build for 1st stage..." ; 

echo " #define CONFIG. SPI. BOOT" >> $ (obj) include/config. h; \ 


echo " define CONFIG_TI81XX_PCIE_BOOT" >> $ (obj) include/config. h ; \ 
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echo "#define CONFIG_SYS_NO_FLASH" >> $ (obj) include/config. h ; V 


echo "#define CONFIG. TISIXX. SPI. BOOT" >> $ (obj) include/config. h ; V 
echo "#define CONFIG_TI81XX_PCIE_64" >> $ (obj) include/config. h ; V 
echo " TI IMAGE =u - boot. min" »» $ (obj) board/ti/ti8168/config. tmp; V 
elif [ " $ (findstring sd, $ 9 )" | ;then | 
echo " #define CONFIG. SYS NO. FLASH" >> $ (obj) include/config. h ; V 
echo " #define CONFIG_MMC_ENV" >> $ (obj) include/config. h ; V 
echo "Setting up TI8168 SD build with ENV in MMC..." ;\ 
elif [ " $ (findstring _ocmc, $  )" | ;then V 
echo " #define CONFIG_SYS_NO_FLASH" >> $ (obj) include/config. h ; V 
echo " #define CONFIG_MINIMAL" >> $ (obj) include/config. h ; V 
echo "TEXT_BASE =0x40410000" >> $ (obj) board/ti/ti8168/ config. tmp; V 
echo "Setting up TI8168 minimal build..." ;\ 
else \ 
echo " #define CONFIG_SYS_NO_FLASH" >> $ (obj) include/config. h ; V 
echo " #define CONFIG_NAND_ENV" >> $ (obj) include/config. h ; V 
echo "Setting up TI8168 default build with NAND. .. " ;\ 


fi; 


, 


€ $ (MKCONFIG) — a ti8168_evm arm arm, cortexa8 ti8168 ti ti81xx 


从 中 可 见 ， 针 对 不 同 启动 设备 的 image， 会 有 两 个 配置 文件 需要 进行 相应 的 设置 。 
是 include/config. h， 男 一 个 就 是 板 级 的 config. tmp。 通 过 这 两 个 文件 ， ne 以 Re 
启动 设备 的 image 了 。 

从 整个 过 程 可 见 ， 不 同 的 处 理 器 的 启动 思路 基本 是 相同 的 ， 相 应 的 差别 主要 在 设备 地 址 
以 及 不 同 设备 的 启动 能 力 上 。 
通常 在 该 部 分 并 没有 信息 输出 到 控制 台 ， 一 般 的 输出 都 是 要 在 boot loader 阶段 才 开 
始 的 。 

3. boot loader 至 内 核 image 

TE ROM Code 将 boot loader 加 载 到 片 内 内 存 之 后 ， 就 会 跳 转 到 相应 的 地 址 执行 boot 
loader 的 代码 。 之 前 已 经 提 到 ，boot loader 被 加 载 的 地 址 和 编译 的 地 址 可 能 不 同 ， 需 要 有 
个 重 定向 的 过 程 。 而 重 定 向 需要 从 片 内 RAM 重 定向 到 内 存 的 空间 ， 而 这 时 内 存 控制 器 等 
并 没有 进行 初始 化 ， 要 求 在 重 定 问 之 前 对 内 存 控制 器 进行 初始 化 。 这 样 就 会 将 整个 boot 
loader 的 流程 实际 分 割 成 两 个 阶段 ， 即 重 定向 之 前 的 阶段 和 重 定向 之 后 的 阶段 。 相 应 的 分 
制 点 就 是 之 前 提 到 的 start. S 中 的 实际 地 址 跳 转 指令 ， 内 容 如 下 : 
























































Idrpe, _start_armboot/ * jump to C code */ 


start. armboot :. word start, armboot 





DM 3730 WY x - loader 其 实 是 基于 u - boot 进行 的 精简 ， 所 以 框架 和 u — boot Zé — 8X 
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的 。 后 面 都 是 以 u - boot 为 例 进行 说 明 。 ( 硬件 设备 初始 化 
第 一 阶段 的 主要 工作 流程 如 图 4-12 所 示 。 b T 


注意 第 一 阶段 由 于 其 所 在 的 空间 # aa ; 
首先 ， 注 意 第 一 阶段 由 于 其 所 在 的 空间 并 不 See 

















是 实际 编译 的 空间 ， 所 以 跳 转 指令 必须 使 用 相对 FRAME THI 
跳 转 。 在 这 一 阶段 主要 初始 化 的 硬件 就 是 内 存 。 À + 
对 于 u — boot 框架 来 说 ， 如 果 人 处 理 右 有 特别 的 底 | 设置 堆栈 指针 














层 初 始 化 操作 需要 进行 ,通常 会 实现 lowlevel | 
init。 这 一 阶段 的 最 终 内 存 初始 化 操作 一 般 都 是 通 6 
过 定义 s_init 函数 实现 的 。 在 这 一 阶段 都 会 有 汇 清空 BSS 段 
编 指令 相对 跳 转 到 C 函数 s_init 中 执行 。 分 别 看 l 
看 DM 3730 和 DM 816X 中 相应 函数 都 进行 了 哪 
DM 3730 的 x — loader 相应 代码 如 下 . 图 4-12 boot loader 第 一 阶段 流程 








跳 转 到 第 二 阶段 入 口 




















void s_init( void) 
| 
watchdog, init( ) ; 
#ifdef CONFIG. 3430. AS 3410 
/ * setup the scalability control register for 
* 3430 to work in 3410 mode 
*/ 
. raw. writel(OxS5ABF,CONTROL SCALABLE OMAP OCP); 
#endif 
try unlock, memory( ) ; 
set, muxconf regs( ) ; 
delay( 100) ; 
prem, init( ) ; 
per. clocks, enable( ) ; 
config 3430sdram, ddr( ) ; 
} 


DM 816X 的 u —boot 相应 的 代码 如 下 : 


void s_init(u32 in_ddr) 
| 


* Disable Write Allocate on miss to avoid starvation of other masters 


* (than A8). 


* Ref DM 816x Erratum; TODO 
*/ 
12. disable, wa( ) ; 
12. cache, enable( ) ; / * Can be removed as A8 comes up with L2 enabled */ 
#ifdef CONFIG. SETUP. 1V 


__raw_writel(0x102, 0x4818155c) ; 
while( (. raw, readl(0x4818155c) & 0x3) ! =0x2); 


__raw_writel(0x102, 0x48181560) ; 
while( (. raw, readl(0x48181560) & 0x3)! 20x2); 


. raw, writel (0x00000001 , 0x4803213c) ; 
. raw, writel ( Oxfffffffü , 0x48032134) ; 
#endif 


prem_init(in_ddr) ; / * Setup the PLLs and the clocks for the peripherals * / 
set, muxconf regs( ) ; 
if (! in ddr) 
config ti$16x sdram ddr(); 7 * Do DDR settings */ 
#ifdef CONFIG_TI816X_VOLT_SCALE 
voltage. scale, init( ) ; 
#endif 
} 
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图 4-13 所 示 ， 根 据 内 存 手册 的 参数 得 到 对 应 寄存 器 的 值 ， 在 相应 的 函数 中 对 控制 寄存 器 写 








OMAP35x Memory Memory OMAP35x 
OMAP35x register bit datasheet | Datasheet Setting 
register name i Decimal 


P 

















= 
zi 
o 
E 
o 
z 
9 
* 
o 
ow 
a 
D 











[Au] 
2 In eles 
AUIII 

















TDAL [4:0] 











TRAS[21:18] [TRP[17:15] [TRCD[14:12] [TRRD[11:9] TDPL[8:6] [reserved 
B 8 3 3 3 


0 
0 
TXSR[7:0] 
17 
00010111 


































01111 
Register value 
hex! 


01011 1000 


7AE1B4C6 


SDRC ACTIM CTRLB p 
reserved[51:18] |TWTR[17:16] |reserved[15] |TCKE[14:12] |reserved[11]| TXP[10:8 

0 2 1 0 
001 0 010 


011 011 010 00110 





























" 0000000000000 [ 


Register value 
hex 


10 








0 














00021217 





SDRC RFR CTRL p 
reserved[31:24] |ARCV[23:8] reserved[7:2] |ARE[2:0] 
00 O5E6 0 














1 








Register Value 
hex) 0005E601 


图 4-13 DM 3730 内 存 控制 器 寄存 器 计 算 工 具 
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入 即 可 。 上 述 的 操作 执行 完毕 ， 外 部 内 存 就 可 以 访 
问 了 。 
内 存 可 以 访问 之 后 ， 就 能 够 进行 代码 搬移 重 定向 操 


board_init 开发 板 相关 的 配置 





timer_init 时 钟 初始 化 





























作 ， 进 入 第 二 阶段。 

第 二 阶段 的 基本 流程 如 图 4-14 所 示 。 nt ERE 

第 二 阶段 主要 进行 外 部 设备 初始 化 操作 ， 这 些 设备 
可 以 进行 kernel 以 及 初始 文件 系统 加 载 ， 所 以 究竟 初始 rit bude S 
化 什么 设备 是 可 以 定制 的 。 之 前 介绍 的 配置 文件 ， 就 可 console init 
以 通过 宏 来 进行 这 部 分 定制 。 相 应 的 设备 初始 化 后 ， | EE 
boot loader 就 进入 主 循 环 ， 等 待命 令 执 行 ,或 者 直接 执 。 QUI 
行 设置 好 的 命令 。 相 应 的 命令 主要 用 于 通过 设备 加 载 内 om。 




















核 image 文件 。 不 要 忘记 boot loader 有 一 个 重要 的 任务 buc € RANA 
就 是 为 内 核 传递 参数 ， 这 就 要 求 可 以 在 boot loader 中 设 = 























HBA, boot loader 主要 通过 其 bootargs 为 内 核 传递 启 bl i DE 

动 参数 。u - boot 中 具体 的 命令 和 参数 在 此 就 不 做 详细 ) 

地 介 绍 了 nand_init NAND Flash 初 始 化 | 
第 二 阶段 最 终 会 通过 boom 命令 跳 转 到 内 核 执行 。 

在 跳 转 进 内 核 image 执行 之 前 ， 还 要 进行 一 些 必要 的 准 ee UMEN 

备 操作 ; 主要 如 下 : Fl 4-14 boot loader 第 二 阶段 流程 





char * commandline = getenv (" bootargs" ) 
s = getenv ("machid" ) 
setup_start_tag (bd) 
setup_end_tag (bd) 
cleanup. before linux( ) 
disable interrupts( ) 
icache, disable( ) 
dcache, disable( ) 
cache, flush( ) 
theKernel (0, machid, bd — bi, boot. params) ; 


这 些 准备 操作 是 准备 参数 、 关 中 断 、 清 理 cache 等 ， 最 终 通 过 theKernel 这 一 指针 跳 转 到 
内 核 image 执行 。 为 什么 一 定 要 进行 这 些 操作 呢 ? 这 些 操作 的 前 世 今生 又 是 怎样 的 呢 ? 其 实 
这 些 操作 都 是 Linux 内 核 规定 boot loader 在 进入 内 核 之 前 必须 做 的 事情 ， 毕 竟 boot loader 和 
Linux 内 核 之 间 统 一 的 接口 是 有 规定 的 。 而 Linux 内 核 需 要 对 处 理 器 进行 很 多 操作 ， 这 些 操 
作 是 在 特权 级 别 并 且 对 系统 初始 化 很 重要 ， 自 人 然 会 对 处 理 右 所 处 的 状态 等 有 严格 的 规定 。 关 
于 ARM 体系 结构 处 理 器 的 相关 限制 在 内 核 的 Documentation/arm/ Booting 文件 中 进行 了 详细 
的 说 明 。 从 如 下 内 容 中 可 见 对 上 述 操作 的 要 求 。 














In any case, the following conditions must be met: 
— Quiesce all DMA capable devices so that memory does not get corrupted by bogus network packets or 


disk data. This will save you many hours of debug. 
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一 CPU register settings 

10 =0, 

rl = machine type number discovered in (3) above. 

12 = physical address of tagged list in system RAM, or physical address of device tree block (dtb) in 
system RAM 


— CPU mode 

All forms of interrupts must be disabled (IRQs and FIQs) 

For CPUs which do not include the ARM virtualization extensions, the CPU must be in SVC mode. (A 
special exception exists for Angel) 

CPUs which include support for the virtualization extensions can be entered in HYP mode in order to 
enable the kernel to make full use of these extensions. This is the recommended boot method for such 
CPUs, unless the virtualisations are already in use by a pre — installed hypervisor. 


If the kernel is not entered in HYP mode for any reason, it must be entered in SVC mode. 


— Caches, MMUs 

The MMU must be off. 

Instruction cache may be on or off. 

Data cache must be off. 

If the kernel is entered in HYP mode, the above requirements apply to the HYP mode configuration in 
addition to the ordinary PLI ( privileged kernel modes) configuration. In addition, all traps into the hy- 
pervisor must be disabled, and PL1 access must be granted for all peripherals and CPU resources for 
which this is architecturally possible. Except for entering in HYP mode, the system configuration should 
be such that a kernel which does not include support for the virtualization extensions can boot correctly 


without extra help. 


— The boot loader is expected to call the kernel image by jumping directly to the first instruction of the 


kernel image. 


On CPUs supporting the ARM instruction set, the entry must be made in ARM state, even for a Thumb 
—2 kernel. 


以 上 部 分 摘自 Linux 内 核 中 的 文档 ， 其 中 对 新 的 技术 ( 如 虚拟 化 和 设备 树 ) 进行 了 详细 


BUE. 3 





这 些 规定 在 做 实际 的 内 核 移 植 是 需要 注意 的 。 





除了 对 处 理 器 状态 等 的 规定 之 外 ， 有 一 点 比较 重要 的 就 是 boot loader 和 Linux 内 核 之 间 


如 何 进 和 











参数 的 交互 。 这 部 分 主要 是 通过 tagged list 来 完成 的 。 对 于 tagged list 来 说 ， 也 是 由 








Linux 内 核 进行 规定 的 ， 同 样 是 在 Booting 文件 中 有 相关 的 描述 。 具 体 的 解释 如 下 (这 里 直接 
进行 了 翻译 ) : 
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boot loader 必须 创建 和 初始 化 内 核 的 tagged list。 一 个 合法 的 tagged list 开始 于 ATAG. CORE 

并 结束 于 ATAG_NONE。ATAG_CORE tag 可 以 为 空 。 一 个 空 的 ATAG_CORE tag 的 size 字段 设 为 
*2" (0x00000002) 。ATAG_NONE 的 size 字段 必须 设 为 “0”。tagged list 可 以 有 任意 多 的 tago 
boot loader 必须 至 少 传递 系统 内 存 的 大 小 和 位 置 ， 以 及 根 文件 系统 的 位 置 ， 一 个 最 小 化 的 tagged list 
























































应 该 如 下 : 





base > | ATAG_CORE | 

| 

| ATAG MEM | | increasing address 

| 

| ATAG_NONE | 

v 

tagged list 应 该 放 在 内 核 解压 后 和 initrd 的 “bootp” 程序 都 不 会 覆盖 的 内 存 区 域 。ARM 体系 结 

构 下 ,建议 放 在 RAM 的 起 始 的 16KB 大 小 的 地 方 。 


























通过 这 段 说 明 ， 回 答 了 之 前 并 没有 解答 的 疑问 zlmage 的 起 始 地 址 设置 为 0x80008000 , 
并 没有 从 内 存 的 首 地 址 开始 ， 而 是 从 32 KB 开始 ， 这 样 为 boot loader 和 参数 的 传递 留 下 足够 
的 空间 ， 另 外 后 面 也 会 看 到 内 核 在 这 32 KB 空间 中 还 有 需要 保存 的 数据 。 

具体 的 参数 及 其 传递 的 内 容 可 以 通过 u - boot 中 include/asm - arm/setup. h 文件 获得 ， 
主要 的 标签 信息 如 下 : 














struct tag | 

struct tag_header hdr; 

union | 
struct tag_corecore ; 
struct tag_mem32mem; 
struct tag_videotextvideotext ; 
struct tag_ramdiskramdisk ; 
struct tag_initrdinitrd ; 
struct tag_serialnrserialnr; 
struct tag_revisionrevision ; 
struct tag_videolfbvideolfb ; 


struct tag_cmdlinecmdline; 


/ * 
* Acorn specific 
*/ 


struct tag acornacorn; 


/* 
* DC21285 specific 
*/ 
struct tag memclkmemclk ; 
mu 


l; 








从 中 可 见 ， 为 扩展 留 出 一 定 的 余地 ， 只 是 要 进行 参数 的 扩展 还 是 需要 在 Linux 内 核 侧 做 
特别 的 定制 工作 。 
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通常 该 玄 阶 YEL 段 结束 会 输 出 如 下 信息 JON ; 


## Booting kernel from Legacy Image at 81000000 . . . 
Image Name: Linux — 2. 6. 37. DM 8127. IPNC. 3. 80. 00 


Created ; 2013-11-27 6:47:24 UTC 
Image Type: ARM Linux Kernel Image (uncompressed ) 
Data Size: 2493848 Bytes =2.4 MiB 


Load Address; 80008000 

Entry Point; 80008000 

Verifying Checksum... OK 

Loading Kernel Image ... OK 
OK 


Starting kernel ... 


接 下 来 就 进入 Linux 内 核 了 。 

4. 内 核 image 至 start kernel 

在 介绍 Linux 内 核 image 生成 中 ,已 经 介绍 了 压缩 image 的 生成 。 所 以 要 进入 Linux 内 核 
image， 首 先 要 做 的 就 是 将 压缩 的 image 进行 解压 缩 操作 。 这 部 分 是 从 boot/compressed 目录 
下 head. S 文件 中 start 处 开始 的 ， 详 细 的 流程 如 图 4-15 所 示 。 
解压 缩 的 过 程控 制 台 会 输出 如 下 信息 : 








Uncompressing Linux... done, booting the kernel. 


解压 缩 结 束 后 ， 最 终 通过 _enter_kernel 加 载 PC 指针 进入 真正 的 内 核 ， 进 行 后 续 的 











这 个 人口 在 arch/arm/kernel/head. S 中 ， 该 文件 就 是 Linux 内 核 真 正 启 动 的 地 方 ， 是 初 
始 化 部 分 的 开始 ， 用 汇编 写成 ， 为 后 面 的 C 代码 初始 化 做 好 准备 。 其 中 有 一 些 宏 定义 需要 
明确 它们 的 含义 ， 具 体 见 表 4-1, 


表 4-1 重要 的 宏 定义 
































4A 代码 位 置 Bk GA 值 说 明 
KERNEL_RAM_ADDR arch/arm/kernel/ head. S 0xC0008000 内 核 在 内 存 中 的 虚拟 地 址 
内 核 虚 拟 地 址 空间 的 起 始 地 址 ， 通 常 是 
PAGE_OFFSET arch/arm/include/asm/memory. h 0xC0000000 P 
内 核 配 置 CONFIG_PAGE_OFTSET 设置 的 
. 内 核 起 始 位 置 相 对 于 内 存 起 始 位 置 的 偏 
TEXT_OFFSET arch/arm/ Makefile 0x00008000 : 
移 ， 一 般 由 textofs — y: =0x00008000 定义 
物理 内 存 的 起 始 地 址 ，DM 3730 芯片 是 
. 、 在 mach - omap2/include/mach/memory. h 
PHYS_OFFSET arch/arm/include/asm/ memory. h Ath FHL AS ASE : 
包含 的 头 文件 plat — omap/include/mach/ 
memory. h 中 定义 
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start 


y 


保存 必要 数据 : 
构架 ID(r1)-->r7 
启动 参数 地 址 (r2)}-->r6 


Y 
关闭 中 断 






































y 


解压 后 内 核 代码 首 地 址 
(内 核 最 终 运行 地 址 ) 
保存 于 r4 


y 




















开启 缓存 机 制 ， 加 速 内 核 自 解压 
(其 中 初始 化 MMU 和 页 表 的 目的 是 为 

了 开启 缓存 ， 因 为 在 ARM 构 架 中 缓存 
开启 是 通过 页 表 项 中 的 位 配置 的 ) 











首次 MMU 初 始 化 后 的 映射 情况 


虚拟 地 址 空间 


256MB 地 址 空间 





v 








获取 实际 运行 地 址 与 编译 时 定义 的 差 值 
(10) ,并 导入 一 系列 地 址 数据 
(编译 时 定义 ) 到 寄存 器 ， 以 备 后 用 








y 


REZE (r0) 校正 地 址 : 
_edata(r6) 
压缩 内 核 数据 结束 地 址 (r10) 











1 人 1 映射 


虚拟 地 址 == 物 理 地 址 





物理 地 址 空间 





MMU+ 页 
表 








256M 地 址 空间 











完成 自我 搬运 后 的 情况 




















刷新 缓存 














A 











A 








vmlinux 


zimage 














16K 
页 表 预 留 空 人 





k 





R9= 当 前 映像 搬运 的 


r10= 解 压 后 的 内 核 结束 地 址 ”目的 地 的 结束 地 址 
4= 解 压 后 的 内 核 起 始 地 址 (最 终 执行 位 置 ) 











Y 


将 解压 后 的 内 核 大 小 数据 
正确 地 放 入 r9 中 














将 当前 的 执行 映像 自 拷贝 到 解压 后 内 核 
代码 所 需 位 置 之 后 〈 必 然 是 向 后 搬运 ) 











Y 


将 正确 的 当前 执行 映像 的 结束 
地 址 放 入 r10 

















是 否 会 发 生 自我 覆盖 
(测试 后 r10 为 解压 后 的 内 核 
结束 地 址 ) 





会 发 生 自我 覆盖 


自我 覆盖 检测 





不 会 发 生 自我 覆盖 


(1) 蓄 最 终 执 行 位 置 M 在 当前 映 "当前 执行 映像 的 结束 地 址 (包含 了 bss/stackjmalloc 空 间 ) 


像 之 后 ,满足 r4-16k 页 目录 鸣 = 解 压 后 的 内 核 起 始 地 址 最终 执 行 位 置 ) 
>=r10， 就 不 会 自我 覆盖 Y 








Y 








修正 GOT 表 项 中 的 地 址 
(根据 配置 ， 可 能 修正 BSS 地 址 ) 





Y 


清 零 BSS 段 
(为 自 解压 代码 做 准备 ) 


Y 


内 核 自 解压 
decompress_kernel 














Y 


刷新 缓存 
关闭 缓存 
(关闭 MMU) 


y 




















zlmage 





vmlinux 























16K 
页 面 预 留 空间 


(2) 才 最 终 执行 位 置 4 在 当前 映像 之 
前 ， 满 足 m4+ 解 压 后 的 内 核 大 小 <= 
当前 位 置 (pc)， 就 不 会 自我 覆盖 











vmlinux 








L. 





| 
16K 
页 面 预 留守 间 





r10= 解 压 后 的 内 核 结束 地 址 


[4= 解 压 后 的 内 核 起 始 地 址 《最 终 执行 位 置 ) 














RO=0 
构架 ID(r7)->r1 
启动 参数 地 址 (r8)->r2 


| om 











mov po,r4 @ 跳 入 解压 后 的 内 核 映 像 入 口 
(arch/arm/kemel/head.S 中 的 入 口 地 址 ) 











图 4-15 Linux 内 核 解压 缩 流程 
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这 些 宏 定 义 之 前 也 见 过 一 些 ， 这 里 进行 详细 说 明 也 凸显 出 它们 的 重要 性 。 这 个 阶段 和 移 
植 相关 的 操作 ， 主 要 就 是 这 些 宏 定 义 的 设置 了 。 

注意 这 里 主要 是 进行 体系 结构 相关 的 初始 化 操作 ， 主 要 的 操作 如 下 : 

首先 检查 处 理 器 类 型 ， 通 过 __ lookup. processor, type 实现 ( arch/arm/kernel/head — 
common. S 中 ) ， 具 体 读 取 processor ID 寄存 器 ， 并 查找 image 中 支持 的 体系 结构 列表 ; 然后 ， 
ixl lookup machine type (arch/arm/kernel/head - common. S 中 ) 查找 image 中 支持 的 处 理 
器 架构 列表 ; 最 后 ， 初 始 化 页 表 ， 该 页 表 在 16 KB ~32 KB 之 间 (ARM 体系 结构 下 主页 表 的 
大 小 就 是 16KB ， 这 样 内 存 的 前 32 KB 就 都 有 用 处 了 ) 通过 __create_page_tables KM, AW 
表 足 够 内 核 进 行 后 续 初 始 化 操作 。 

处 理 恬 特别 的 操作 通常 是 _switch_data 和 __enable_mmu (arch/arm/mm/proc - *.S 中 
实现 ) 。 后 续 还 有 初始 化 TLB 、caches ， 最 终 使 能 MMU。 紧 接着 就 跳 转 到 虚拟 地 址 执行 。 下 
面 来 看 看 如 何 实现 这 个 跳 转 的 。 注 意 在 跳 转 到 虚拟 地 址 之 前 通常 还 是 用 相对 跳 转 进行 函数 调 
用 的 。 















































ldr r13, =_ mmap_switched @ address to jump to after mmu has been enabled 
@ 这 里 绝对 地 址 是 虚拟 地 址 
adr lr, BSYM( 1f) @ return (PIC) address 


ARM( add pc, r10, #PROCINFO_INITFUNC) 
THUMB( add r12, r10, #PROCINFO_INITFUNC) 
THUMB( mov pe, r12) 


1: b enable mmu 


. turn mmu on: 
mov 10, 10 
mcr pl5, 0, 10, cl, c0, 0 ( write control reg 
mre pl5, 0, 13, c0, c0, 0 @ read id reg 
mov r3, r3 
mov r3, r13 @ 这 里 将 之 前 保存 的 虚拟 地 址 取出 
mov pe, 13 @ 调转 到 相应 的 虚拟 地 址 

















这 一 阶段 的 具体 流程 如 图 4-16 所 示 。 
Linux 内 核 到 这 里 ， 就 要 进入 start_kernel 来 进行 C 代码 级 别 的 初始 化 操作 了 。DM 3730 
的 流程 中 调用 和 地 址 关系 如 图 4-17 所 示 。 








5. start_kernel 2 rest_init 

start. kernel 函数 是 在 Linux 内 核 的 init 目录 下 的 main. c 文件 中 。 看 到 文件 名 就 知道 ， 这 
其 中 包含 了 Linux 内 核 初 始 化 的 主要 函数 ， 而 start. kernel 则 是 重 中 之 重 ， 如 此 重要 的 函数 有 
必要 完整 读 一 遍 。 这 里 以 2.6.37 内 核对 应 函数 为 例 ， 并 会 将 解释 说 明和 代码 混合 在 一 起 
直接 在 每 行 代码 之 前 以 注释 的 形式 ) ， 这 样 可 以 结合 代码 一 起 理解 。 该 函数 也 是 了 解 Linux 
内 核 各 个 模块 一 个 非常 好 的 人 口 。 
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ENTRY(stext) 


























从 CPI5 获 取 处 理 器 ID--->r9 




















不 匹配 
error p 


打印 错误 信息 检测 处 理 器 ID 是 否 匹 配 











! 











匹配 


Y 
获取 RAM 的 起 始 物理 地 址 ， 保 存 于 





. error 
死 循环 








R8 = phys_offset 


Y | 


判断 [2 〈 内 核 启 动 参数 ) 指针 的 有 效 性 
检测 内 容 是 否 有 效 


























清 零 16K 的 一 级 初始 页 表 区 
这 些 页 表 在 内 核 自 解压 时 被 设置 过 
(此 时 MMU 已 关闭 》 











Y 





获取 节 描述 符 的 默认 配置 

















KERNEL_END 





KERNEL, ST 











0xC0000000 








为 启动 MMU 做 最 后 准备 : 
(1) 设 置 启动 MMU 后 跳 转 的 第 一 个 虚拟 地 址 (r13) 
(2) 保 存 页 目录 物理 地 址 (r8)， 以 备 启动 MMU 时 放 入 TTBR1 





' 





跳 入 构架 相关 的 初始 化 处 理 器 函数 
(例如 A8 的 是 _V7_setup) 
目的 : 初始 化 TLB,Caches， 让 MMU 状 态 满足 启用 的 条 件 





1:1 映 射 《 物 理 地 址 : 


物理 内 存 



































. mmap switched 























如 果 是 XIP 技 术 内 核 ， 
复制 数据 段 到 内 存 


y 
清 零 BSS 段 


y 


将 需要 的 数据 从 寄存 器 中 
转移 到 全 局 变量 中 






































4-16 Linux 内 核 进入 C 代码 之 前 的 初始 化 流程 
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V 


图 4-17 DM 3730 初始 化 流程 调 


stext(0xc0008000) 


. lookup processor type(0xc00084e0) 


. create page tables(0xc000803c) 


. V7 proc info(0xc0031190) 


. V7 setup(0xc0030760) 


v7 flush dcache all(0xc006798c) 


. enable mmu(0xc00082a0) 


. turn mmu on(0xc00082c0) 


. mmap. switched(0xc0008460) 


start kernel(0xc008848) 














asmlinkage void _ init start, kernel( void ) 


| 


char * command_line; 


和 地 址 关系 


// 这 里 的 变量 是 在 链接 时 产生 的 ,Linux 内 核对 参数 的 管理 是 将 它们 统一 放 到 一 个 section 
//_param 中 ,这 样 就 需要 知道 setction 的 起 始 和 结束 地 址 ,在 链接 脚本 中 通过 include/asm — 
// generic/ vmlinux. Ids. h 将 这 两 个 变量 加 入 





extern const struct kernel, param __start__param| 











|, _stop__param|[ ] ; 











// 这 里 试图 对 SMP 架构 的 不 同 处 理 器 进行 逻辑 标定 ,具体 的 处 理 器 号 通常 是 硬件 做 的 标记 ， 














/所 以 这 里 通常 是 启动 时 启动 处 理 顺 号 的 逻辑 映射 。 注 意 该 函数 在 main. c 中 由 

















pa 
Fg p 
F3 I1 








E weak 


// 定 义 ,这 样 体系 结构 相关 代码 可 以 重 定 义 该 函数 。 对 于 老 的 内 核 ARM 体系 结构 ,一般 这 





// 是 空 函 数 ;对 于 新 的 内 核 ,该 函数 进行 处 理 器 逻辑 标定 。 处 至 





// 的 ARM 系统 结构 中 大 核 小 核 (big. little) 也 是 需要 的 


smp. setup. processor. id( ); 


/o* 


* Need to run as early as possible, to initialize the 


* lockdep hash: 
*/ 














// 这 里 是 内 核 调 试 相关 功能 的 初始 化 
//lockdep 是 用 来 检查 内 核 中 各 种 锁 的 状态 ,用 于 检查 、 调 试 内 核 因 不 正确 的 使 用 锁 造 成 的 
// 死 锁 问 题 ,在 内 核 debug 配置 中 有 相应 的 功能 配置 








lockdep_init( ) ; 











Edi EPRE D EGET decr 











// 内 核 中 很 多 动态 对 象 是 有 生命 周期 的 ,debug object 作为 库 来 提供 给 其 他 模块 ,用 于 调试 模 
// 块 内 ( 如 timer) 对 动态 对 象 的 非法 操作 问题 (如 有 效 对 象 非法 释放 ) 


debug_objects_early_init( ) ; 








J * 
* Set up the the initial canary ASAP; 
*/ 
//stack canary 用 于 检测 栈 溢 出 ,canary 是 金 丝 管 , 古 时 候 使 用 金 丝 瞧 来 检查 煤矿 中 是 否 安 全 ， 
// 这 里 就 是 使 用 这 个 典故 。 通常 的 做 法 是 在 栈 上 做 一 个 特殊 值 作为 标记 ,这 个 值 需 要 在 这 里 
/进行 初始 化 ,该 标记 值 就 应 该 叫 金 丝 稚 


boot_init_stack_canary() ; 






























































//cgroup 是 control group 的 缩写 ,是 Linux 内 核 提 供 的 一 种 可 以 限制 记录、 隔离 进程 组 (process 
//groups) 所 使 用 的 物理 资源 ( 如 CPU „memory IO SE) 的 机 制 。cgroup 是 一 种 管理 资源 的 方 
// 式 ,也 是 后 来 才 引 进 Linux 内 核 的 。 这 里 是 该 功能 基本 管理 数据 的 初始 化 操作 ,该 功能 还 
// 在 很 多 云 应 用 中 使 用 


cgroup_init_early( ) ; 




































































// 在 内 核 没 有 准备 好 接收 中 断 之 前 , 先 将 中 断 关闭 。 中 断 通常 是 随机 事件 ,发 生 问题 时 的 
// 现 象 也 是 随机 的 ,所 以 在 内 核准 备 好 接收 中 断 之 前 要 主动 关闭 中 断 
local_irq_disable( ) ; 

// 这 里 是 对 启动 时 中 断 关 闭 进行 状态 标定 ,该 标定 主要 用 于 特别 操作 的 状态 检查 ,如 果 检 查 
// 到 与 状态 有 关联 操作 的 执行 则 可 以 进行 报警 

early_boot_irqs_off( ) ; 





























J * 

* Interrupts are still disabled. Do necessary setups, then 

* enable them 

*/ 
// 这 里 是 Linux 内 核 时 间 系 统 的 部 分 功能 的 初始 化 。iick 是 滴答 ,滴答 和 时 间 的 间隔 相关 ,而 
//tick 在 Linux 内 核 中 是 驱动 管理 时 间 的 框架 ,这 里 的 初始 化 主要 是 将 tick 提供 的 控制 管理 
// 接 口 注 册 到 系统 中 
tick_init( ) ; 
// 标 记 当 前 启动 的 CPU 的 状态 为 激活 状态 
boot_cpu_init( ) ; 
// 这 里 是 针对 highmem 的 管理 实体 的 初始 化 。highmem 的 每 个 page 需要 进行 单独 映射 ,所 以 
// 这 里 初始 化 相应 的 地 址 映射 管理 结构 
page. address, init( ) ; 
// 输 出 Linux version 2. 6. 37 … 等 编译 内 核 相 关 的 信息 
printk( KERN, NOTICE " 96s" , linux banner) ; 
// 体 系 结构 相关 的 初始 化 ,并 且 获 得 内 核 的 启动 参数 。 其 中 会 涉及 中 断 向 量 表 的 重 定位 以 及 
// 板 级 初始 化 信息 的 加 载 。 这 个 重要 的 初始 化 步 又 后 续 会 详细 说 明 。 体 系 结构 相关 初始 化 
/过 程 中 会 输出 一 些 处 理 器 以 及 板 级 的 信息 


setup_arch( &command line) ; 
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// 这 里 指定 Linux 内 核 的 内 存 管理 结构 的 owner 为 内 核 初始 的 init, task 进程 ,该 功 能 通过 
//CONFIG_MM_OWNER 进行 配置 ,通常 不 配置 该 功能 

mm_init_owner( &init, mm, &init_task) ; 

// 将 启动 参数 进行 保存 以 便 后 续 处 理 

setup_command_line( command_line) ; 

/ SU SCE Ab BE tt 

setup_nr_cpu_ids() ; 

// 初 始 化 每 个 CPU 的 私有 空间 ,这 些 私 有 空间 存放 CPU 的 私有 数据 。 这 部 分 数据 可 以 不 使 
/人 /用 自 旋 锁 进 行 保 护 ,这样 可 以 提高 性 能 。 单 处 理 器 和 SMP 处 理 器 不 同 
setup_per_cpu_areas( ) ; 

// 这 里 属于 标记 启动 CPU 的 根 进程 


smp_prepare_boot_cpu( ) ;/ * arch — specific boot — epu hooks */ 







































































// 下 面 是 对 于 物理 页 管理 的 相关 初始 化 
// 内 存 物 理 页 分 为 不 同 的 zone 区 域 ,对 所 有 的 node 中 的 zone 管理 进行 初始 化 
build_all_zonelists( NULL) ; 

// 对 所 有 的 处 理 器 建立 page 分 配 通知 机 制 


page_alloc_init( ) ; 



































// 这 里 把 boot loader 传人 的 命令 行进 行 输出 

printk( KERN, NOTICE "Kernel command line; % s\n" , boot, command line) ; 
// 进 行 早期 的 参数 解析 ,主要 是 和 控制 台 相 关 

parse early param( ) ; 

// 进 行 完 整 的 参数 解析 ,static_command_line 是 之 前 static. command, line 保存 的 


parse_args("Booting kernel" , static. command line, __start__param, 











. stop param — start param, 
&unknown_bootoption ) ; 
/ok 
* These use large bootmem allocations and must precede 
* kmem, cache. init( ) 
*/ 
/初始 化 0(1) 调 度 算法 需要 的 PID 哈 希 表 
// 这 里 会 输出 信息 :PID hash table entries; 512 (order; —1, 2048 bytes) 
pidhash, init( ) ; 
//NES 早期 的 初始 化 ,主要 还 是 管理 哈 希 表 的 初始 化 
// 这 里 会 输出 信息 
//Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) 
//Inode — cache hash table entries; 8192 (order; 3, 32768 bytes) 
vfs, caches, init, early( ) ; 
// 对 内 核 特定 的 异常 表 ( exception table ) 初始 化 ,按照 异常 号 大 小 进行 排序 
// 这 里 是 内 核 提 供 的 一 些 异常 修复 功能 ,散布 在 内 核 很 多 地 方 ,属于 横 切 功能 


sort main, extable( ) ; 
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/人 /体系 结构 相关 的 trap 初始 化 。ARM 体系 结构 下 为 空 , 内 核 中 断 异 常 使 用 向 量 表 的 初始 化 
// 在 early_trap_init 中 进行 





trap_init() ; 

// 现 在 就 可 以 对 内 核 标 准 的 内 存 分 配方 式 进行 初始 化 。 该 初始 化 之 后 ,各 个 模块 就 可 以 
// 使 用 标准 的 内 核 内 存 分 配方 式 分 配 和 使 用 内 存 。 在 此 之 前 的 初始 化 ,工作 内 核 提 供 了 
//bootmem 分 配方 式 ,这 里 一 并 释放 相应 的 资源 

/注意 这 里 只 是 初始 化 分 配器 ,对 于 实际 物理 页 资源 的 初始 化 是 在 和 体系 结构 相关 的 setup_ 
//arch 中 进行 的 。 这 里 会 输出 物理 内 存 信 息 和 虚拟 地 址 映射 信息 
mm_init() ; 


/* 






































* Set up the scheduler prior starting any interrupts (such as the 

* timer interrupt). Full topology setup happens at smp_init( ) 

* time — but meanwhile we still have a functioning scheduler. 

*/ 
// 初 始 化 调度 器 的 管理 结构 ,主要 是 各 个 CPU 的 各 种 优先 级 管理 资源 以 及 运行 队列 。 注意 
[idle 作 为 一 个 特殊 的 任务 ,需要 在 每 个 处 理 器 上 进行 特别 的 标注 ,以 便 调 度 时 进行 特别 操作 
sched init( ) ; 
J * 

















* Disable preemption — early bootup scheduling is extremely 

* fragile until we cpu. idle( ) for the first time. 

*/ 
/虽然 调度 器 已 经 准备 就 绪 , 但 是 不 应 该 在 系统 初始 化 期 间 将 初始 化 的 任务 抢占 ,所 以 这 里 
// 禁 止 内 核 抢占 。 等 到 后 续 系 统 初始 化 完成 ,再 打开 该 功能 
preempt_disable() ; 
// 内 核 抢 占 功能 关闭 ,但 是 担心 之 前 体系 结构 相关 初始 化 打开 中 断 ,导致 后 续 的 初始 化 出 现 问 
// 题 ,所 以 这 里 检查 一 下 是 否 中 断 disable, 这 样 可 以 提早 发 现 ,提早 报警 ,以 避免 一 些 随机 的 问题 
if (! irqs_disabled() ) | 

printk( KERN, WARNING "start_kernel( ) : bug; interrupts were " 


"enabled * very * early, fixing it\n" ) ; 












































local_irq_disable() ; 
} 
// ARKH Read - Copy - Update 的 初始 化 ,该 功能 主要 是 在 SMP 下 一 种 高 效 的 读 写 锁 机 制 ， 
// 通 过 限定 更 新 的 时 间 点 来 进行 数据 保护 和 同步 ,可 以 配置 不 同 的 实现 方式 
rcu, init( ) ; 
[初始 化 Radix 树 ,是 一 种 快速 查找 的 搜索 树 。 在 Linux 内 核 中 ,包括 cache 机 制 等 多 种 功 
// 能 都 采用 该 数据 结构 加 速 


radix_tree_init( ) ; 












































/ * init some links before init_ISA_irqs() * / 

]/ 初 始 化 Linux 内 核 的 中 断 处 理 模块 ,主要 是 体系 结构 无 关 的 中 断 描述 结构 

early_irq_init( ) ; 

// 这 里 不 仅 是 体系 结构 相关 还 是 处 理 器 相关 的 板 级 中 断 初始 化 操作 ,相应 的 函数 接口 是 在 
//setup_arch 中 加 载 的 
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init IRQ() ; 

// 初 始 化 基于 radix 的 优先 级 查找 树 ,该 数据 结构 3 
prio tree init( ) ; 

// 这 里 进行 timer 管理 结构 的 初始 化 。 如 果 是 SMP ,会 初始 化 每 个 CPU 的 timer 管理 结构 
init, timers( ) ; 


/初始 化 高 精度 定时 器 功能 。 主 要 提高 系统 的 时 钟 精度 (到 纳 秒 级 别 ) 














要 用 在 虚拟 地 址 空间 的 管理 中 











H 
































hrtimers, init( ) ; 
// 初 始 化 软 中 断 等 中 断 处 理 后 半 部 的 功能 
softirq_init( ) ; 
// 初 始 化 Linux 内 核 的 时 间 更 新 系统 ,该 系统 功能 是 保证 系统 时 间 的 正确 和 稳定 
timekeeping_init( ) ; 
// 对 于 系统 相关 的 系统 时 钟 进行 初始 化 ,系统 时 钟 指 定 是 在 setup. arch 中 ,从 板 级 信息 中 
// 获 得 的 
time_init( ) ; 
初始 化 Linux 内 核 的 性 能 调试 功能 
profile init( ) ; 
// 之 前 执行 过 体系 结构 相关 的 代码 ,为 了 避免 问题 ,这 里 再 检查 一 遍 中 断 是 否 被 打开 
if (! irqs_disabled( ) ) 
printk( KERN, CRIT "start, kernel( ) ; bug; interrupts were " 
























































"enabled early\n" ) ; 
// 之 前 标记 系统 状态 ,检查 中 断 关 闭 状态 ,现在 可 以 设置 为 中 断 打 开 了 
early. boot, irqs. on( ) ; 
/进行 中 断 使 能 操作 


local_irq_enable( ) ; 





/ * Interrupts are enabled now so all GFP allocations are safe. * / 
// 这 里 可 以 允许 所 有 情况 下 的 物理 内 存 页 分 配 功 能 
gfp_allowed_mask =__GFP_BITS_MASK; 




















// ARATE cache 分 配 需 的 后 续 初 始 化 工作 。 有 slab slob 和 slub 几 种 实现 


kmem, cache. init, late( ) ; 


/ox 
* HACK ALERT! This is early. Wé re enabling the console before 
* we ve done PCI setups etc, and console init( ) must be aware of 
* this. But we do want output early, in case something goes wrong. 
*/ 

// 控 制 台 初始 化 ,这 样 可 以 尽早 看 到 启动 信息 

console_init( ) ; 

// 之 前 如 果 解 析 参 数 有 问题 ,这 里 可 以 输出 相应 信息 

if ( panic, later) 











panic( panic, later, panic, param) ; 
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// 输 出 lockdep 功能 的 属性 及 使 用 资源 的 信息 
lockdep_info( ) ; 











Je 

* Need to run this when irqs are enabled, because it wants 

* to self — test | hard/soft | — irqs on/off lock inversion bugs 

* too; 

*/ 
// 在 系统 运行 之 前 检查 一 下 各 种 锁 的 功能 是 否 正 常 , 主 要 用 于 调试 
locking_selftest() ; 





#ifdef CONFIG_BLK_DEV_INITRD 
// Xf initrd 进行 位 置 检查 
if (initrd_start && ! initrd_below_start_ok && 

page. to. pfn( virt, to page( (void * )initrd start) ) <min_low_pfn) | 
printk( KERN. CRIT "initrd overwritten ( 0x96 081x «0x96081x) — " 
"disabling it. \n" , 





page. to. pfn( virt, to page( (void * )initrd start) ) , 
min low. pfn) ; 
initrd, start 20; 
} 
#endif 
// XX BFE memory cgroup 功能 初始 化 。memory cgroup 是 cgroup 体系 中 提供 的 对 于 memory 资 
// 源 管理 的 功能 
page cgroup. init( ) ; 
// 使 能 对 于 物理 页 分 配器 的 debug 功能 ,该 功能 可 以 配置 
enable debug pagealloc( ) ; 
// VAR VA TIERE 0] TERIS s A 
kmemleak  init( ) ; 
// 初 始 化 动态 对 象 调 试 工具 所 需 的 内 存 ,通过 kmem, eache 分 配器 创建 
debug_objects_mem_init( ) ; 
// YD 管理 功能 的 所 需 内 存 初 始 化 ,同样 是 通过 kmem_cache 分 配器 创建 
//YD 管理 功能 是 建立 ID 和 指针 的 关联 ,比如 了 PC 的 从 地 址 和 管理 结构 的 管理 
idr_init_cache() ; 
/为 每 个 CPU 分 配 一 定 的 物理 页 
setup_per_cpu_pageset( ) ; 
// 非 一 致 性 内 存 策略 初始 化 ,功能 和 物理 内 存 的 分 布 相关 ,向 入 式 通常 不 需要 该 功能 
numa_policy_init() ; 
// 与 体系 结构 相关 的 时 间 系 统 后 半 部 的 初始 化 函数 ,通常 ARM 下 为 空 


if (late_time_init) 





















































































































































late_time_init( ) ; 


//sched_clock 主要 是 启动 后 的 时 间 ,以 纳 秒 为 单位 ,如 记录 timestamp 功能 。 这 里 使 能 该 功能 
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sched. clock, init( ) ; 

// ThE ESSERE , T EM ta EISE 30 HR sr RE PLAIRE 
// Calibrating delay loop. .. 599.65 BogoMIPS (lpj = 2998272) 

calibrate, delay( ) ; 

// XJ PID 管理 所 需 的 内 存 进 行 分 配 

pidmap. init( ) ; 

// 对 于 匿名 映射 的 vma 管理 实体 分 配 内 存 , 并 初始 化 


anon_vma_init( ) ; 






































#ifdef CONFIG_X86 


if (efi enabled) 


efi enter virtual. mode( ) ; 


#endif 





//thread_info 通常 是 在 进程 的 内 核 栈 低地 址 。 通 常 为 
thread_info_cache_init( ) ; 

// 初 始 化 Credentials ,这 是 在 Linux 内 核 中 ,用 来 管控 权限 的 机 制 。 通 常用 于 检查 用 户 的 访问 权限 等 
cred_init( ) ; 
// 初 始 化 fork 机 制 , 参 考 totalram_pages 决定 可 以 创建 进程 数量 max_threads 
fork_init(totalram_pages ) ; 

/初始 化 进程 中 各 种 资源 ( 信号 相关 文件 系统 相关 虚拟 地 址 管理 相关 等 ) 需 要 的 内 存 
proe, caches, init( ) ; 

/初始 化 文件 系统 buffer 的 管理 空间 

buffer_init() ; 

// 内 核 密 匙 管理 系统 初始 化 

key_init( ) ; 

// 内 核 安全 框架 初始 化 

security_init( ) ; 

人 内核 调试 系统 后 期 初始 化 

dbg_late_init() ; 

// 初 始 化 虚拟 文件 系统 VFS 需要 的 dcache 和 inode cache 空间 
vfs_caches_init(totalram_pages ) ; 

// 信 号 管理 的 初始 化 ,主要 是 初始 化 信号 队列 的 空间 


signals_init() ; 











Br 















































/ * rootfs populating might need page — writeback * / 

// 初 始 化 文件 系统 writeback 回 写 机 制 ,会 产生 pdflush 内 核 线程 来 执行 被 修改 的 
// 页 Cache 的 回 写 操 作 

page_writeback_init( ) ; 








#ifdef CONFIG_PROC_FS 














[人 /初始 化 proc 文件 系统 ,主要 用 于 查看 和 设置 内 核 的 信息 


proe, root, init( ) ; 

















#endif 


// 内 核资 源 管理 功能 的 初始 化 
cgroup_init( ) ; 





// Xt CPU 资源 管理 功能 的 初始 化 

cpuset_init( ) ; 

/人 /任务 统计 网 络 发 送 功能 的 初始 化 
taskstats init, early( ) ; 

// 用 于 统计 task 等 待 资 源 消耗 时 间 的 功能 初始 化 


delayacct_init( ) ; 




















uu 








// 检 查处 理 器 是 否 有 特殊 的 bug, bug E SZ WWE] Ze Mb ilg. cache, tlb 和 分 支 预测 造成 的 write 
// buffer 一 致 性 的 问题 ( 原理 是 对 通过 不 同 虚 拟 地 址 映射 的 相同 物理 地 址 写 和 人 数值 后 ,检查 
// 最 后 的 结果 是 否 正确 ) 

check_bugs( ) ; 
































// 对 高 级 控制 和 电源 管理 接口 进行 初始 化 ,ARM 体系 结构 通常 为 空 
acpi early init( ) ;/ * before LAPIC and SMP init */ 


sfi_init_late() ; 


//ftrace 提供 对 于 内 核 的 各 种 追踪 功能 


ftrace_init() ; 


/ * Do the rest non -, init ed, we re now alive */ 
// 后 续 的 内 核 初始 化 
rest_init( ) ; 


| 


通过 start_kernel, 可 以 对 Linux 内 核 的 各 个 模块 的 功能 有 一 个 基本 的 了 解 。 可 以 看 到 
Linux 内 核 还 是 提供 了 丰富 的 工具 来 帮助 开发 者 调试 和 管理 整个 系统 。 

6. rest_init 和 kernel_init 

基本 的 系统 功能 都 已 经 初始 化 好 ， 而 且 中 断 已 经 使 能 ， 下 面 就 可 以 准备 接收 外 部 事件 
了 。 但 是 不 要 忘 了 ， 内 核 抢 占 还 是 disable 的 ， 并 没有 使 能 。 此 时 系统 中 只 有 一 个 进程 ， 其 
他 进程 是 在 rest_init 中 创建 的 ， 图 4-18 是 rest_init 的 主要 框架 。 

从 图 4-18 中 可 见 ，Linux 内 核 中 有 三 个 最 基本 的 任务 进程 ， 分 别 为 PID =0 (只 是 相当 
于 并 没有 该 PID) 的 idle 任务 (就 是 之 前 提 到 的 需要 处 理 器 进行 特殊 标记 的 任务 ); PID =1 
的 任务 ， 负 责 初 始 化 所 有 用 户 系统 相关 进程 的 init 任务 ; UK PID =2 任务 ,负责 产生 内 核 
线程 的 kthreadd 任务 。 

SEH ps 查看 Linux 所 有 进程 时 ,会 有 如 下 信息 。 从 中 可 见 PID 是 从 1 开始 的 ， 而 头 两 
个 任务 就 是 在 rest_init 中 创建 的 。 





























USER PID % CPU % MEM VSZ RSS TTY STAT START TIME COMMAND 
root 1 0.0 0.0 24732 2612 ? Ss 09:27 0:00 /sbin/init 
root 2 0.0 0.0 0 0? S 09:27 0:00 [ kthreadd | 
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Boot Task/ 


Per-CPU Idle Task 
Kernel_init(PID=1) 


stext 


X User-Mode 


start_kernel init Task(PID=1) 


\ 


rest_init 


N 


Kernel Thread 
kernel_init 


kthreadd Task 


Kernel Thread |o E (PID=2) 


kthreadd 


cpu_idle 


Q 


Enter Power Saving Mode 
When CPU enter IDLE Task 




















图 4-18 rest_init 框架 图 





接 下 来 看 看 rest. init 的 代码 : 


static noinline void __init_refok rest_init( void) 


| 
int pid; 





/启动 RCU 机 制 ,之 后 就 可 以 使 用 了 
rcu, scheduler. starting( ) ; 
/* 


* We need to spawn init first so that it obtains pid 1, however 





* the init task will end up wanting to create kthreads, which, if 
* we schedule it before we create kthreadd, will OOPS. 
*/ 
// 创 建 init 任务 的 内 核 线程 ( 内 核 中 资源 都 是 可 见 ,所 以 不 需要 进程 的 概念 ) ,相应 的 PID 是 
//1。 内 核 线程 会 执行 kernel_init 来 进行 后 续 的 操作 
kernel_thread( kernel. init, NULL, CLONE FS | CLONE_SIGHAND) ; 
// 设 定 NUMA 的 策略 
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numa_default_policy() ; 

// 创 建 PID 为 2 的 任务 ,kthreadd 主要 用 于 创建 内 核 线 程 

pid = kernel_thread ( kthreadd, NULL, CLONE_FS | CLONE FILES) ; 

// 下 面 是 RCU 保护 区 域 

rcu, read. lock( ) ; 

// 获 得 kthreadd 的 task. struct 结构 ,并 保存 在 全 局 变量 kthread, task 中 。 这 个 全 局 变量 作为 
// Linux 系统 中 守护 进程 的 父 进程 。 这 是 由 于 init 进程 拥有 控制 台 ,是 普通 进程 的 父 进程 ， 
// 而 守护 进程 也 需要 父 进程 在 其 退出 时 为 其 释放 资源 

kthreadd_task = find_task_by_pid_ns( pid, &init_pid_ns); 

rcu_read_unlock( ) ; 

// 注 意 内 核 中 要 创建 新 的 任务 ,通常 需要 kthread_create 接口 ,保证 干净 的 上 下 文 。 而 kthread_ 
//create 则 需要 内 核 线程 kthreadd 来 进行 后 续 操作 ,所 以 这 里 由 complete 来 完成 同步 ,允许 
//init 进行 后 续 操 作 

complete ( &kthreadd, done) ; 
























































/* 

* The boot idle thread must execute schedule( ) 

* at least once to get things moving: 

*/ 
// 进 程 有 不 同 的 调度 类 型 ,而 对 于 当前 的 进程 ,之 前 已 经 说 明 是 作为 idle 进程 ,其 调度 应 该 
// 在 所 有 进程 都 不 在 运行 状态 时 才 执 行 。 这 样 就 要 将 其 归 入 特别 的 idle 类 型 ,该 函数 就 是 
// 执 行 这 个 操作 
init_idle_bootup_task ( current ) ; 
// 现 在 已 经 有 多 个 进程 了 ,应 该 允许 调度 和 抢占 了 ,首先 允许 内 核 抢占 
preempt_enable_no_resched( ) ; 
// 这 里 进行 调度 ,由 调度 需 决 定 是 否 切换 到 其 他 进程 执行 
schedule( ) ; 
// 到 这 里 说 明 没有 其 他 任务 在 运行 状态 ,那么 当前 CPU 要 进行 idle 的 操作 ,在 进行 idle 操作 
// 期 间 不 能 切换 到 其 他 进程 执行 ,所 以 要 禁止 内 核 抢占 
preempt_disable( ) ; 
























































/ * Call into cpu_idle with preempt disabled * / 

// ANAT cpu_idle 操作 ,让 处 理 器 休息 一 下 ,函数 内 最 终 是 死 循环 ,切换 到 idle 进程 就 休息 一 下 
// 以 达到 节能 的 效果 

cpu, idle( ) ; 














对 Linux 内 核 初始 化 讲 到 现在 ， 仍 然 没 有 看 到 设备 相关 的 初始 化 ， 各 种 设备 的 初始 化 是 
在 哪里 执行 的 呢 ? 接 下 来 看 看 kernel_init 会 有 些 什 么 发 现 。 


static int __init kernel_init( void * unused) 


| 
/ * 
* Wait until kthreadd is all set — up. 
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*/ 
// 由 于 后 续 操作 需要 通过 PID 为 2 AY kthreadd 创建 内 核 线程 ,所 以 这 里 等 待 内 核 线程 
//kthreadd 创建 完成 
wait_for_completion( &kthreadd_done) ; 
Je 





* init can allocate pages on any node 

*/ 
// init 进程 的 权限 大 ,可 以 在 所 有 的 内 存 区 域 获得 内 存 页 ,这 里 进行 相应 的 设置 
set_mems_allowed( node_states[ N_HIGH_MEMORY |] ) ; 
pe 
































* init can run on any cpu. 
*/ 
// 同 样 init 进程 应 该 可 以 在 所 有 的 CPU 上 执行 
set cpus allowed ptr(current, cpu all mask) ; 
Ie 
* Tell the world that we re going to be the grim 
* reaper of innocent orphaned children. 
* 
* We don t want people to have to make incorrect 
* assumptions about where in the task array this 
* can be found. 
*/ 
// Linux 系统 中 ,对 于 孤儿 进程 的 托管 ,是 由 init 进程 完成 的 ,相应 的 设置 就 在 这 里 
init_pid_ns. child_reaper = current; 
//init 进程 还 是 处 理 ctrl — alt — delete 操作 的 进程 ,进行 相应 的 设置 
cad_pid = task, pid( current) ; 
信和 体系 结构 相关 ,为 不 同 的 CPU 运行 做 准备 
smp. prepare cpus( setup_max_cpus ) ; 
// 执 行 早期 的 initeall, 主要 是 段 initcallearly. init 的 函数 ,包括 workqueue 的 初始 化 等 需要 早 
// 期 的 初始 化 操作 
do_pre_smp_initcalls( ) ; 
// 这 里 激活 SMP 的 其 他 处 理 器 
smp. init( ) ; 
/运行 所 有 的 CPU 执行 
sched, init, smp( ) ; 
// 接 下 来 就 是 和 设备 及 驱动 相关 的 初始 化 执行 了 。 只 是 对 于 Linux 内 核 ,将 各 个 驱动 的 初始 
// 化 放 在 了 不 同 级 别 的 initeall 中 进行 顺序 调用 ,相应 的 接口 函数 是 do_initcalls ,当然 在 这 之 
// 前 还 有 必要 的 初始 化 (如 设备 模型 ) 执 行 。 后 续 会 有 详细 介绍 
do_basic_setup( ) ; 









































/ * Open the /dev/console on the rootfs, this should never fail * / 


// 后 续 通 用 进程 都 要 打开 的 文件 分 别 是 标准 输入 输出 和 错误 , 均 指 向 控制 台 





























if (sys_open( (const char _ user * ) "/dev/console" , O_RDWR, 0) <0) 
printk( KERN, WARNING "Warning: unable to open an initial console. \n" ) ; 


(void) sys dup(0) ; 

(void) sys dup(0); 

fe 
* check if there is an early userspace init. If yes, let it do all 
* the work 
*/ 

// 如 果 需 要 进行 早期 的 应 用 init 操作 


if (! ramdisk_execute_command ) 
































ramdisk_execute_command = " /init" ; 
if (sys_access( (const char __user * ) ramdisk_execute_command, 0) ! 20) | 
ramdisk_execute_command = NULL; 


prepare namespace( ) ; 


/* 

* Ok, we have completed the initial bootup, and 

* we re essentially up and running. Get rid of the 

* initmem segments and start the user — mode stuff. . 

*/ 
// 进 行 后 续 的 初始 化 ,主要 是 在 文件 系统 中 查找 最 终 的 init 程序 ,并 执行 。 整 个 进程 也 会 完 
/全 被 用 户 的 程序 替代 。 之 前 提 到 的 对 于 只 在 初始 化 中 需要 的 空间 ,如 初始 化 函数 的 空间 
// 等 ,都 会 在 这 里 进行 释放 。 这 样 系统 才 进 入 真正 的 执行 状态 
init_post( ) ; 
































return 0; 


初始 化 时 的 initeall 是 比较 繁杂 的 ， 涉 及 操作 系统 中 的 各 个 层面 和 功能 ， 还 和 体系 结构 
相关 。 为 了 方便 查找 和 理解 ， 笔 者 以 DM 3730 系列 芯片 内 核 为 基础 ， 列 出 了 相应 initcall 的 
安定 义 以 及 函数 位 置 供 读者 参考 。 











#define early, initeall(fn) ^ define. initcall( " early" ,fn,early) 


arch/arm/mach - omap2/omap4- common. c ; early. initcall( omap. 12. cache init) ; 
kernel/relay. c ; early. initcall( relay. init) ; 

kernel/sched. c: early, initcall( migration init) ; 

kernel/smp. c; early. initcall(init, call. single data) ; 

kernel/softirq. c : early, initcall( spawn, ksoftirqd ) ; 


kernel/stop. machine. c ; early, initcall( cpu, stop. init) ; 
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kernel/trace/ trace. c ; early, initeall(tracer alloc buffers); 

kernel/trace/trace printk. c ; early. initcall( init, trace, printk ) ; 
kernel/trace/trace workqueue. c ; early. initcall( trace workqueue, early. init) ; 
kernel/watchdog. c ; early, initcall( spawn, watchdog task) ; 


kernel/workqueue. c ; early, initcall( init, workqueues ) ; 


#define pure, initeall(fn).— define initcall( "0" ,fn,0) 





drivers/ cpufreq/cpufreq. c; pure. initcall(init cpufreq transition. notifier list) ; 


net/core/net, namespace. c;pure. initcall( net, ns. init) ; 


#define core, initeall(fn). define initcall( "1" ,fn,1) 
arch/arm/mach - omap2/ pm. bus. c; core, initcall( omap, pm. runtime init) ; 
arch/arm/plat — omap/omap. device. c ;core, initcall( omap. device, init) ; 
drivers/ base/ power/trace. c : core_initcall ( early resume init) ; 
drivers/ cpufreq/cpufreq. c: core. initcall( cpufreq core. init) ; 
drivers/ cpuidle/cpuidle. c; core. initcall( cpuidle_init) ; 
drivers/ regulator/core. c : core, initcall( regulator init) ; 
drivers/ video/omap2/ dss/core. c ; core, initcall( omap. dss init) ; 
fs/ debugfs/inode. c: core, initcall( debugfs init) ; 
kernel/cpu. c; core, initcall(alloc. frozen cpus) ; 
kernel/power/hibernate. c ; core, initcall( pm. disk init) ; 
kernel/power/ main. c; core, initcall( pm. init) ; 
kernel/power/swap. c; core, initcall( swsusp. header init) ; 
kernel/sysctl. c; core, initcall( sysctl, init) ; 
kernel/time/ jiffies. c: core initcall(init, jiffies clocksource) ; 
kernel/trace/trace syscalls. c ; core initcall( init, ftrace. syscalls) ; 
mm/ backing — dev. c ; postcore_initcall ( bdi, class init) ; 
mm/ memory. c ; core, initcall( init, zero, pfn) ; 
net/core/netpoll. c; core, initcall( netpoll init) ; 
net/core/sock. c;core initcall( net inuse init) ; 
net/netlink/af netlink. c; core, initcall( netlink, proto init) ; 


net/socket. c;core initcall(sock, init) ; / * early initcall */ 


#define postcore_initcall( fn) define initcall( "2" ,fn,2) 
drivers/ base/ node. c ; postcore_initcall ( register node, type) ; 
drivers/ char/tty, io. c: postcore initcall(tty class init) ; 
drivers/ char/ vt. c ; postcore, initcall( vtconsole class init) ; 
drivers/ gpio/ gpiolib. c :postcore initcall( gpiolib sysfs init) ; 
drivers/i2c/i2c — core. c ; postcore, initcall(i2e init) ; 
drivers/spi/spi. c; postcore, initcall( spi init) ; 
drivers/ video/backlight/backlight. c ; posteore_initeall ( backlight, class init) ; 
drivers/ video/backlight/led. c ; postcore, initcall(led class init) ; 
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drivers/ video/ output. c ; postcore_initcall ( video, output, class init) ; 


mm/ backing — dev. c ; postcore_initcall ( bdi, class init) ; 


#define arch, initcall(fn). define initcall( "3" ,fn,3) 
arch/arm/kernel/atags. c ; arch, initcall( init, atags procfs) ; 
arch/arm/kernel/perf. event. c ; arch, initcall( init, hw. perf. events) ; 
arch/arm/kernel/setup. c ; arch, initcall( customize machine) ; 
arch/arm/mach - omap2/ clock2xxx. c; arch, initeall( omap2xxx, clk arch init) ; 
arch/arm/mach - omap2/clock3 xxx. c; arch, initeall( omap3xxx, elk arch init) ; 
arch/arm/mach - omap2/ devices. c ; arch, initcall( omap2, init, devices) ; 
arch/arm/mach - omap2/ mcbsp. c ; arch, initcall ( omap2, mebsp. init) ; 
arch/arm/mach - omap2/ pm - debug. c ; arch, initeall( pm, dbg init) ; 
arch/arm/plat — omap/32ksynctimer. c ; arch, initcall( omap. init, elocksource 32k) ; 
arch/arm/plat — omap/cpu — omap. c ; arch, initeall( omap. epufreq. init) ; 
arch/arm/plat ~ omap/ devices. c ; arch, initeall( omap. init, devices ) ; 
arch/arm/ plat — omap/dma. c ; arch, initcall( omap. init, dma ) ; 
arch/arm/plat — omap/fb. c ; arch, initeall( omap. init, fb) ; 
arch/arm/plat — omap/fb. c ; arch, initeall( omap. init, fb) ; 
arch/arm/plat — omap/gpio. c ; arch, initcall( omap. gpio. sysinit ) ; 
drivers/ dma/ dmaengine. c ; arch, initcall( dma, channel, table init) ; 
drivers/ dma/ dmaengine. c ; arch, initcall( dma, bus init) ; 
drivers/ video/omap2/ vram. c ; arch, initcall( omap_vram_init) ; 


sound/soc/omap/ mepdm. c ; arch, initcall (omap. mepdm, init) ; 


#define subsys_initcall( fn) define initcall( " 4" ,fn,4) 
arch/arm/mach - omap2/ devices. c ; subsys, initcall( omap. init, wdt) ; 
arch/arm/mach - omap2/ emu. c ; subsys. initcall ( emu, init) ; 
drivers/ char/ misc. c ; subsys. initcall ( misc, init) ; 
drivers/ connector/connector. c ; subsys. initcall( cn init) ; 
drivers/ dma/ipu/ipu, idmac. c ; subsys. initcall( ipu, init) ; 
drivers/ gpio/ gpiolib. c :subsys. initcall( gpiolib debugfs init) ; 
drivers/i2 c/busses/i2c — omap. c; subsys_initcall( omap, i2e init, driver) ; 
drivers/input/input. c;subsys_initcall ( input. init) ; 
drivers/leds/led — class. c : subsys, initcall( leds init) ; 
drivers/ mfd/twl — core. c ; subsys_initcall ( twl_init) ; 
drivers/ mmc/ core/ core. c ; subsys, initcall( mmc, init) ; 
drivers/net/phy/phy. device. c ; subsys, initcall( phy, init) ; 
drivers/ power/ power. supply. core. c ; subsys_initcall( power. supply. class init) ; 
drivers/ regulator/twl — regulator. c; subsys, initcall( twlreg init) ; 
drivers/rtc/class. c ; subsys initcall( rte. init) ; 
drivers/spi/omap2, mespi. c:subsys initeall( omap2. mespi init) ; 


kernel/params. c ;subsys. initcall( param, sysfs init) ; 
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kernel/ power/ poweroff. c; subsys_initcall (pm_sysrq_init) ; 
lib/raid6/algos. c: subsys_initcall ( raid6, select, algo) ; 
net/core/ dev. c ;subsys. initcall( net, dev. init) ; 
net/core/sock. c ; subsys, initcall( proto. init) ; 
sound/core/sound. c; subsys, initeall( alsa sound init) ; 


sound/sound core. c ; subsys_initcall ( init, soundcore ) ; 


#define fs initeall(fn). define initcall( " 5" ,fn,5) 
arch/arm/plat — omap/debug — leds. c fs initcall(fpga init) ; 
drivers/base/firmware, class. c ; fs. initcall( firmware, class. init) ; 
drivers/ char/ mem. c ; fs_initcall( chr dev. init) ; 
drivers/ cpufreq/cpufreq. conservative. c ;fs initcall( epufreq. gov, dbs init) ; 
drivers/ cpufreq/cpufreq_ondemand. c: fs_initcall ( cpufreq. gov. dbs. init) ; 
drivers/cpufreq/cpufreq. performance. c:fs initcall( cpufreq- gov. performance init) ; 
drivers/ cpufreq/cpufreq_powersave. c ; fs_initcall ( cpufreq_gov_powersave_init) ; 
drivers/ cpufreq/cpufreq_userspace. c ; fs_initcall ( cpufreq_gov_userspace_init ) ; 
drivers/usb/musb/musb_core. c ;fs_initcall( musb init) ; 
fs/cachefiles/main. c;fs initcall( cachefiles init) ; 
init/initramfs. c ; rootfs initcall( populate_rootfs ) ; 
init/noinitramfs. c :rootfs initcall( default. rootfs ) ; 
kernel/time/ clocksource. c ; fs. initcall( clocksource, done, booting) ; 
kernel/trace/ftrace. c :fs initcall(ftrace init, debugfs) ; 
net/core/sysctl net core. c:fs initcall(sysctl core init) ; 


net/ipv4/af_inet. c ;fs initcall( inet. init) ; 


#define rootfs, initcall(fn). define. initcall( " rootfs" , fn, rootfs ) 
init/initramfs. c ; rootfs  initcall( populate, rootfs ) ; 


init/noinitramfs. c :rootfs initcall( default. rootfs ) ; 


#define device. initeall(fn), define initcall( "6" ,fn,6) 
arch/arm/mach - omap2/ pm. c ; device, initcall( omap2. common, pm init) ; 
drivers/ base/topology. c ; device, initcall( topology. sysfs, init) ; 


drivers/ video/omap2/ dss/core. c ; device, initcall( omap. dss. init2) ; 


#define late initcall(fn). define initcall( " 7" ,fn,7) 
arch/arm/kernel/crunch. c ;late, initeall( crunch, init) ; 
arch/arm/kernel/thumbee. c late, initeall( thumbee. init) ; 
arch/arm/kernel/traps. c ; late, initeall( arm, mre, hook, init) ; 
arch/arm/mach - omap2/ mux. c ; late_initcall (omap_mux_late_init) ; 
arch/arm/mach - omap2/pm24xx. c ;late. initcall( omap2, pm. init) ; 
arch/arm/mach - omap2/ pm34xx. c ;late  initcall( omap3, pm. init) ; 
arch/arm/mach - omap2/ pm44xx. c ;late, initcall( omap4. pm init) ; 
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arch/arm/ plat - omap/clock. c ; late_initeall ( clk, disable unused); 


arch/arm/ plat — omap/clock. c ; late_initeall ( clk_debugfs_init) ; 


drivers/ base/ power/ trace. c ; late_initcall (late_resume_init) ; 


drivers/ block/hd. c ; late, initcall( hd, init) ; 


drivers/ char/ random. c ;late, initcall( seqgen. init) ; 


drivers/ dma/ dmatest. c ;late, initcall( dmatest, init) ; 


drivers/ regulator/core. c ; late_initeall ( regulator init, complete) ; 


drivers/ video/omap2/ omapfb/omapfb — main. c ; late, initcall( omapfb init) ; 


kernel/kprobes. c late initcall( debugfs kprobe init) ; 


kernel/panic. c :1 


ate initcall( init, oops. id) ; 


kernel/pm, qos. params. c ;late, initcall( pm. qos power. init) ; 


kernel/power/hibernate. c ; late, initcall( software resume) ; 


kernel/power/suspend test. c ; late_initcall ( test, suspend) ; 


kernel/printk. c ; late, initcall( printk, late init) ; 


kernel/sched. c;late initcall( sched, init debug) ; 


kernel/taskstats. c ;late, initcall( taskstats init) ; 


kernel/trace/ trac 


mm/ kmemleak. c 


e. c :late, initcall( clear boot, tracer) ; 


:late initcall( kmemleak. late. init) ; 


mm/ page. alloc. c ;late, initcall( fail, page. alloc. debugfs) ; 


mm/ swapfile. c :1 


ate initcall( max, swapfiles check); 


net/core/ dev. c ;late initcall sync( initialize_hashrnd ) ; 


net/core/drop. m 


onitor. c ;late initcall(init, net, drop. monitor) ; 


net/ipv4/ipconfig. c;late initcall(ip. auto, config) ; 


从 这 些 initcall 中 可 以 看 出 ， 很 多 功能 模块 、 设 备 驱 动 框架 和 设备 驱动 的 初始 化 操作 





都 集中 在 这 里 进行 了 。 当 然 这 些 初始 化 并 不 都 执行 ， 这 和 内 核 的 配置 相关 ， 但 是 对 了 解 




















明确 各 个 模块 的 初始 化 流程 还 是 很 有 帮助 的 。 后 面 讲 到 具体 驱动 的 时 候 会 详细 介绍 相应 


的 初始 化 操作 。 


7. 体系 结构 和 板 级 相关 的 初始 化 
对 Linux 系统 初始 化 有 了 整体 的 认识 之 后 ， 现 在 回 过 头 来 看 看 体系 结构 相关 和 板 级 相关 


的 初始 化 操作 setup_arch ( 
对 于 做 系统 移植 还 是 十 分 习 








ARM 体系 结构 下 在 arch/arm/kernel/setup. c 中 ) 。 这 其 中 的 细节 
E 要 的。 以 下 是 DM 3730 内 核 2. 6. 37 版 本 的 相关 setup_ arch ft 





码 ， 虽 然 版 本 有 些 老 ， 但 相应 的 机 制 是 相同 的 。 


void __init setup_arch 


| 


struct tag * tags 


(char * * cmdline_p) 


= (struct tag * ) &init, tags; 


struct machine, dese * mdesc; 


char * from = default, command, line; 


// 体 系 结构 相关 的 , 栈 上 调用 链 展开 功能 的 初始 化 。 该 功能 主要 用 于 调试 时 查看 栈 上 的 函数 


// 调 用 关系 


unwind_init( ) ; 
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// 再 次 检测 处 理 器 类 型 JEW i AB TH OS BUE ES A SE RS A T f eL ER 
// 过 这 个 函数 打印 的 。 会 输出 如 下 信息 

//CPU; ARMv7 Processor [413fc082 | revision 2 ( ARMv7) , cr =10c53c7f 

//CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache 

// 加 载重 要 的 数据 结构 proc_info_list, 其 中 包括 了 处 理 器 内 部 ub cache 等 操作 的 具体 接口 。 
// 具 体 的 实现 是 在 arch/arm/mm/ proc — *. S 中 (处 理 器 相关 ) 


setup_processor( ) ; 






















































































/加载 板 级 相关 的 信息 。 主 要 是 针对 板 级 特殊 的 信息 和 初始 化 实体 。 这 里 会 对 machine_ 

//arch_type 进行 检查 ,而 包括 machine, arch. type 的 生成 需要 板 级 一 系列 操作 。machine_arch_ 
//type 的 生成 需要 arch/arm/tools/ mach -types 中 加 入 相应 的 信息 ,在 Keonfig 中 加 入 相应 的 配 
// 置 ,这 样 才能 在 对 内 核 进行 正确 的 配置 后 ,生成 正确 的 machine_arch_type。 在 板 级 文件 中 则 
// 通 过 宏 MACHINE START 中 的 正确 属性 名 形成 正确 的 machine, desc 属性 定义 ,最 终 才 能 匹 

// 配 成 功 


mdesc = setup_machine( machine, arch, type) ; 









































machine_name = mdesc —> name; 














// 设 置 板 级 重启 的 方式 ,是 软 重启 还 是 硬 重启 。 体 系 结构 中 都 有 重启 的 接口 ,如 ARM 的 
//arm_machine_restart, 而 其 中 会 调用 特别 的 处 理 器 的 接口 函数 arch_reset( DM 3730 是 定义 
// TE. plat/system. h 中 ) ,通过 该 函数 完成 真正 系统 重启 操作 。DM 3730 的 实现 就 是 调用 
//PRCM 接口 rest IIb TIERS 

if ( mdesc — soft, reboot ) 





















































reboot, setup( " s" ) ; 





// 下 面 开 始 就 是 对 boot loader 传人 的 参数 进行 处 理 了 。 注 意 对 于 新 的 device tree 架构 实现 这 
// 部 分 会 不 相同 


if (_ atags pointer) 








tags = phys_to_virt(__atags_pointer) ; 
else if ( mdesc — boot_params ) 


tags = phys, to. virt( mdesc — boot_params ) ; 


#if defined( CONFIG_DEPRECATED_PARAM_STRUCT) 


/ok 
* If we have the old style parameters, convert them to 
* a tag list. 

*/ 
if (tags — hdr. tag | = ATAG, CORE) 


convert, to. tag list(tags) ; 


#endif 


if (tags > hdr. tag |! =ATAG_CORE) 


tags = (struct tag * ) &init_tags; 





/如 果 需 要 则 根据 参数 所 在 内 存 区 域 对 系统 内 存 信息 进行 修 
if (mdesc — fixup) 





mdesc —> fixup( mdesc, tags, &from, &meminfo) ; 


if (tags — hdr. tag ==ATAG_CORE) | 
if ( meminfo. nr banks ! =0) 
squash mem, tags( tags) ; 
save atags(tags) ; 


parse, tags( tags) ; 














正 ,通常 不 需要 








// 对 于 内 核 的 memory 管理 实体 , 当然 要 知道 内 核 的 各 个 重要 











段 的 位 置 ,这 里 对 这 些 信息 进 








// 行 初始 化 

init_mm. start_code = (unsigned long) _text; 
init_mm. end_code = (unsigned long) _etext; 
init_mm. end_data = (unsigned long) _edata; 


init_mm. brk = (unsigned long) | end; 


/ * parse early param needs a boot, command line * / 
strlepy ( boot, command, line, from, COMMAND LINE SIZE) ; 


/ * populate cmd line too for later use, preserving boot, command, line * / 


strlepy( emd, line, boot, command line, COMMAND LINE SIZE 


* emdline p = emd line; 





DE 


// 对 需要 尽早 解析 的 内 核 参 数 进行 解析 ,是 通过 early param 定义 的 参数 ,如 mem 等 。 对 参数 


























// 解 析 时 会 根据 mem 进行 meminfo 的 设置 


parse_early_param( ) ; 














// 在 此 处 按 地 址 数据 从 小 到 大 排序 meminfo 中 的 数据 ,并 初始 化 全 局 的 内 存 块 (memblock ) 数 





// 据 。 需 要 注意 的 是 , 板 级 特性 有 可 能 会 保留 一 部 分 空间 进行 
//desc 中 有 保留 空间 的 接口 reserve ,会 在 这 里 被 调用 


arm_memblock_init( &meminfo, ，mdesc ) ; 








// 建 立 页 表 , 页 表 实 际 就 是 最 终 的 映射 。 实 际 的 系统 还 需要 zero 页 和 bad 页 来 对 一 些 地 址 进 
// 行 特别 的 映射 ,实现 一 定 的 功能 。 男 外 板 级 特别 的 映射 和 问 量 表 也 在 该 处 进行 处 理 , 通 过 


//devicemaps_init 实现 。 最 后 ,初始 化 阶段 的 bootmem 分 配器 
// 址 映射 的 细节 后 续 会 进行 讲解 
paging_init( mdesc ) ; 





// 对 于 地 址 这 一 资源 要 先 将 已 有 的 资源 请 求 出 来 ,其 中 这 里 3 


// 会 包括 板 级 视频 显卡 ,PCI 以 及 系统 内 存 等 


request_standard_resources( &meminfo, mdesc) ; 


特别 的 管理 和 操作 。machine_ 


























也 在 这 里 进行 初始 化 。 对 于 地 





要 针对 的 是 iomem 进行 请 求 ， 
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#ifdef CONFIG_SMP 
// 针 对 SMP 处 理 器 ,初始 化 可 能 存在 的 CPU 映射 
if (is smp()) 

smp. init, cpus( ) ; 

#endif 

// 通 过 内 核 参 数 中 的 crashkernel ,保留 下 


reserve_crashkernel() ; 























FEY ASTIN BR AE fii AVE 











ay 














I 


[初始 化 CPU 及 
cpu, init( ) ; 
// 对 片 内 的 TCM 类 型 内 存 进行 初始 化 。 


tem_init() ; 


栈 。 








/ * 
* Set up various architecture — specific pointers 
*/ 

/初始 化 各 种 板 级 相关 的 指针 ,后 续 初 始 化 (已 经 在 之 前 的 内 容 介绍 了 ) 会 使 用 


arch. nr irqs = mdesc — nr. irqs; 

















init arch, irq = mdesc — init, irq; 

system. timer = mdesc —» timer; 

// 注 意 这 里 的 init; machine 是 在 arch. initeall( 见 之 前 initcall 的 内 容 ) 的 customize. machine 
// 中 调用 的 


init, machine = mdesc -> init, machine; 




















// 根 据 配置 对 控制 台 进 行 特别 处 理 
#ifdef CONFIG_VT 
#if defined( CONFIG_VGA_CONSOLE ) 
conswitchp = &vga_con; 
#elif defined( CONFIG DUMMY CONSOLE) 
conswitchp = &dummy. con; 
#endif 
#endif 
// 这 里 进行 向 量 表 的 初始 化 ,主要 是 将 entry - armv. S 中 的 代码 复制 到 相应 的 地 址 空间 ,使 得 
// 系 统 可 以 正常 执行 。 向 量 表 的 实际 物理 页 是 在 之 前 的 paging_init 执行 中 ,通过 vectors = early. 
//alloc( PAGE, SIZE) ;进行 分 配 的 
early_trap_init( ) ; 
































| 


最 后 ， 再 来 看 看 板 级 相关 的 初始 化 接口 的 定义 。 以 DM 3730 EVM 板 的 代码 为 例 ， 在 
mach — omap2 目录 下 的 board - omap3evm. c 中 实现 。 详 细 内 容 如 下 : 





MACHINE_START( OMAP3EVM, "OMAP3 EVM") 
. boot_params =0x80000100, 


. map. io = omap3. map io, 
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. reserve = omap_reserve , 


. Init. irq = omap3. evm init irq, 
.init machine =omap3_evm_init, 
. timer = &omap. timer, 


MACHINE END 


这 里 的 接口 都 是 板 级 相关 的 接口 ， 对 于 其 中 的 说 明 以 及 在 初始 化 中 的 使 用 ， 之 前 的 内 容 
已 经 说 明 ， 具 体 的 实现 这 里 就 暂时 放 一 放 ， 会 在 对 应 的 功能 中 进行 详细 介绍 。 需 要 说 明 的 是 
init_machine 接口 ， 这 个 接口 对 于 开发 板 是 十 分 重要 的 。 因 为 板子 上 所 有 的 设备 信息 初始 化 
都 是 通过 该 接口 来 实现 的 ， 其 会 在 arch_initcall 中 被 调用 ， 通 常 早 于 设备 驱动 初始 化 。 这 样 
驱动 初始 化 后 就 能 正常 使 用 设备 了 。 函 数 具 体 的 信息 如 下 : 
































static void __init omap3_evm_init( void) 


| 


omap3_evm_get_revision( ) ; 


if (get_omap3_evm_rev() > =OMAP3EVM_BOARD_GEN_2) 
omap3evm_twldata. vaux2 = &omap3evm_vaux2 ; 
else 


omap3evm_twldata. vusb = &omap3_evm_vusb; 


if ( epu, is omap3630( ) ) 

omap3, mux, init( omap36x, board mux, OMAP PACKAGE CBB); 
else 

omap3, mux, init( omap35x, board mux, OMAP PACKAGE CBB); 


omap3_evm_i2c_init() ; 


platform, add, devices( omap3. evm, devices, ARRAY, SIZE( omap3, evm, devices) ) ; 


spi register board, info( omap3evm, spi board info, 
ARRAY, SIZE( omap3evm. spi, board, info) ) ; 


omap. serial init( ) ; 


/* OMAP3EVM uses ISP1504 phy and so register nop transceiver */ 


usb. nop. xceiv, register(0) ; 


#ifndef CONFIG MACH. FLASHBOARD 
if (get_omap3_evm_rev( ) > = OMAP3EVM. BOARD GEN 2) | 
/ * enable EHCI VBUS using GPIO22 */ 
omap. mux, init, gpio(22, OMAP. PIN INPUT PULLUP) ; 
gpio_request( OMAP3  EVM, EHCI, VBUS, "enable EHCI VBUS" ) ; 
gpio. direction output( OMAP3_EVM_EHCI_VBUS, 0); 
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gpio_set_value( OMAP3_EVM_EHCI_VBUS, 1); 


/ * Select EHCI port on main board * / 

omap. mux, init, gpio(61, OMAP. PIN INPUT PULLUP); 
gpio_request( OMAP3 EVM, EHCI, SELECT, "select EHCI port" ) ; 
gpio. direction output( OMAP3, EVM, EHCI, SELECT, 0) ; 
gpio. set. value( OMAP3_EVM_EHCI_SELECT, 0) ; 


/ * setup EHCI phy reset config * / 
omap. mux, init, gpio(21, OMAP_PIN_INPUT_PULLUP) ; 
ehci_pdata. reset, gpio. port| 1 ] 221; 


/* EVM REV > =E can supply 500mA with EXTVBUS programming * / 
musb. board. data. power = 500; 
musb, board, data. extvbus 21 ; 
| else | 
/ * setup EHCI phy reset on MDC */ 
omap. mux, init, gpio( 135, OMAP. PIN. OUTPUT) ; 
ehci_pdata. reset, gpio. port[ 1] 2135; 
} 
#else 
if (get_omap3_evm_rev() > =OMAP3EVM_BOARD_GEN_2) | 
/ * EVM REV > =E can supply 500mA with EXTVBUS programming * / 
musb_board_data. power = 500; 
musb_board_data. extvbus =1; 
} 
#endif 
usb_musb_init( &musb_board_data) ; 
#ifndef CONFIG_MACH_FLASHBOARD 
usb_ehci_init( &ehci_pdata) ; 
#endif 
ads7846_dev_init() ; 
omap3evm_init_smsc911x() ; 


omap3_evm_display_init( ) ; 


#ifdef CONFIG_USB_ANDROID 
omap3evm, android, gadget, init( ) ; 
#endif 


omap3_evm_pm_init() ; 


/* NAND */ 
board nand init( omap3, evm, nand, partitions, 
ARRAY. SIZE( omap3. evm nand partitions) , 
0, NAND BUSWIDTH. 16) ; 
#ifndef CONFIG MACH, FLASHBOARD 
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board onenand init( omap3_evm_onenand_partitions , 
ARRAY. SIZE( omap3. evm onenand, partitions) , 0) ; 
#endif 
#ifdef CONFIG_WLI2XX_PLATFORM_DATA 
/* WLI2xx WLAN Init * / 
if (wl12xx_set_platform_data( &omap3evm_wlan_data) ) 
pr. err( " error setting wl12xx data\n" ) ; 
platform_device_register( &omap3evm_wlan_regulator) ; 
#endif 
#ifdef CONFIG_TI_ST 
omap3evm_init_btwilink() ; 
#endif 
#ifdef CONFIG_SND_SOC_WL1271 BT 
wl1271bt_clk_setup() ; 
#endif 
} 


从 中 可 见 初 始 化 涉及 芯片 的 封装 类 型 、 引 脚 复 用 和 各 种 设备 〈 包 括 TC、SPI、 电 源 、USB 
等 )。 每 种 初始 化 细节 留 到 相应 功能 和 设备 驱动 部 分 时 详 述 。 

至 此 ， 包 括 核 心 处 理 器 和 板 级 的 设备 初始 化 的 框架 都 进行 了 说 明 ， 整 个 初始 化 部 分 就 比 
较 完 整 了 。 














4.2 地址 映射 


4.2.1 地 址 映射 的 基本 需求 

Linux 内 核 中 人 处理 器 使 用 的 是 虚拟 地 址 ， 而 无 论 内 存 还 是 物理 设备 的 地 址 都 是 物理 地 址 ， 
这 就 需要 进行 虚拟 地 址 到 物理 地 址 的 映射 。 地 址 映射 在 内 核 的 初始 化 阶段 会 输出 类 似 如 下 的 
i (DM 3730 EVM 内 核 的 输出 )， 从 这 些 信息 中 可 以 了 解 内 核 地 址 映射 的 基本 情况 。 











Virtual kernel memory layout: 
vector : Oxffff0000 —OxfffflO00 (4 kB) 
fixmap : Oxfff00000 — Oxfffe0000 — (896 kB) 
DMA  : Oxffc00000 —Oxffe00000 (2 MB) 
vmalloc : 0xe0800000 —0xf8000000 — (376 MB) 
lowmem : 0xe0000000 —0xe0000000 (512 MB) 
modules : Oxbf000000 —0xc0000000 (16 MB) 
. init : 0xc0008000 —0xc002f000 (156 kB) 
. text : 0xc002f000 —0xc0515000 — (5016 kB) 
. data : 0xc0516000 —0xc05514e0 (238 kB) 


地 址 映射 首先 要 符合 体系 结构 的 需求 。 毕 竞 每 种 体系 结构 都 有 自己 特点 ， 而 地 址 本 身 就 
属于 体系 结构 的 一 部 分 。 比 如 32 位 和 64 位 的 系统 地 址 空间 都 有 数量 级 的 差别 ， 自 然 地 址 映 
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射 是 不 同 的 。 
在 一 个 体系 结构 之 下 ， 要 考虑 的 因素 主要 就 是 内 存 的 容量 。 地 址 映射 要 能 够 支持 各 种 容 
量 的 内 存 〈 当 然 首先 要 处 理 器 能 够 访问 到 ) 。 即 使 地 址 空间 不 够 ， 如 果 物 理 上 能 够 访问 ， 也 
需要 想 办 法 访问 更 多 的 内 存 空 间 。 

容量 的 需求 是 一 方面 ， 空 间 使 用 的 需求 则 是 要 尽量 减少 分 配 不 到 的 情况 。 这 就 需要 在 映 
射 设计 时 考虑 不 同 的 映射 方式 〈 这 部 分 和 内 存 管理 有 相关 性 ) 。 

在 映射 这 个 大 的 功能 下 ， 之 前 讨论 的 主要 是 对 内 存 的 使 用 ， 而 对 于 操作 系统 来 说 更 大 的 
一 部 分 是 设备 的 使 用 ,设备 10 空间 同样 要 进行 映射 。 只 有 符合 体系 结构 的 映射 才能 够 从 处 
理 器 访问 到 设备 ， 访 问 设备 就 要 考虑 设备 本 身 的 限制 了 7， 所 以 在 做 映射 的 时 候 要 考虑 设备 的 
特殊 需求 。 

总 之 ， 对 于 整个 内 核 空间 的 地 址 映射 设计 就 是 在 操作 系统 层面 ,综合 考虑 体系 结构 、 内 
存 需 求 、 处 理 器 、 设 备 和 内 核 效 率 的 结果 。 


4.2.2 ”地址 映射 框架 介绍 


首先 要 明确 ， 这 里 讲述 的 地 址 映射 框架 主要 是 指 内 核 空间 虚拟 地 址 的 使 用 和 映射 。 
mmap 等 用 户 空间 的 映射 相关 功能 会 在 内 存 管理 和 实际 的 设备 驱动 部 分 再 进行 介绍 。 

1. ARM 体系 结构 空间 分 配 

对 于 地 址 映射 框架 ,首先 要 考虑 的 就 是 体系 结构 。 岗 入 式 系统 通常 是 采用 ARM 的 处 理 器 ， 
相应 的 地 址 映射 框架 自然 就 从 Linux 内 核 的 ARM 体系 结构 人 手 。 相 应 的 地 址 映射 ， 内 核 大 牛 们 已 
经 为 开发 人 员 设 计 好 地 址 空间 的 分 布 并 制定 了 规范 ， 相应 的 信息 如 下 ( 摘自 Documents/arm/ 
memory. tx 文件 ) 。 注 意 ARM 体系 结构 和 相应 的 Linux 内 核 支持 也 是 不 断 演进 的 ， 相 应 的 地 址 映 
射 也 会 随 之 进行 一 定 的 变化 ,但 是 通常 都 是 增加 相应 的 细 化 空间 ， 而 不 是 进行 大 的 调整 。 



















































































StartEndUse 





ffffS000 — ffffffff ^ copy user page / clear user page use. 
For SA11xx and Xscale, this is used to 


setup a minicache mapping. 


ffffA000 — ffffffff ^ cache aliasing on ARMv6 and later CPUs. 


ffff1000  ffff/fff Reserved. 


Platforms must not use this address range. 


ffff0000 — ffffO0fff CPU vector page. 
The CPU vectors are mapped here if the 
CPU supports vector relocation ( control 


register V bit. ) 


Íffe0000 — fffeffff XScale cache flush area. This is used 
in proc — xscale. S to flush the whole data 
cache. (XScale does not have TCM. ) 
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fffe8000 — fffeffff DTCM mapping area for platforms with 
DTCM mounted inside the CPU. 


fffe0000 — fffe7fff ITCM mapping area for platforms with 
ITCM mounted inside the CPU. 


fff00000 — fffdffff Fixmap mapping region. Addresses provided 
by fix to. virt( ) will be located here. 


ffc00000 ffefffff DMA memory mapping region. Memory returned 
by the dma_alloc_xxx functions will be 


dynamically mapped here. 


ff000000 — ffbfffff Reserved for future expansion of DMA 


mapping region. 


fee00000 feffffff Mapping of PCI I/O space. This is a static 


mapping within the vmalloc space. 


VMALLOC START VMALLOC END-1  vmalloc( ) / ioremap( ) space. 
Memory returned by vmalloc/ioremap will 
be dynamically placed in this region. 
Machine specific static mappings are also 
located here through iotable_init(). 
VMALLOC, START is based upon the value 
of the high memory variable, and VMALLOC END 
is equal to Oxff000000. 


PAGE OFFSET | HIGH. MEMORY - I Kernel direct - mapped RAM region. 


This maps the platforms RAM, and typically 
maps all platform RAM in a 1:1 relationship. 


PKMAP BASE — PAGE OFFSET - I Permanent kernel mappings 
One way of mapping HIGHMEM pages into kernel 


space. 


MODULES VADDR MODULES END -1 Kernel module space 
Kernel modules inserted via insmod are 


placed here using dynamic mappings. 


00001000 TASK SIZE -1 User space mappings 
Per — thread mappings are placed here via 


the mmap( ) system call. 


00000000 O00000fff CPU vector page / null pointer trap 
CPUs which do not support vector remapping 
place their vector page here. NULL pointer 
dereferences by both the kernel and user 


space are also caught via this mapping. 
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32 位 的 ARM 系统 ， 整 个 的 地 址 空间 只 有 4 GB ， 其 中 还 要 为 用 户 应 用 保留 大 部 分 的 地 址 
空间 ， 所 以 通常 来 说 32 位 体系 结构 会 保留 1GB 左右 的 地 址 空间 给 内 核 使 用 。 对 于 这 1 GB 的 
空间 ， 向 量 表 的 位 置 是 不 允许 移动 的 。ARM 体系 结构 中 向 量 表 可 以 是 低地 址 或 者 高 地 址 两 
种 模式 ， 通 常 处 理 器 都 是 使 用 高 地 址 。 其 他 的 空间 则 根据 需要 进行 设计 。 

从 映射 说 明文 档 中 可 见 ， 在 ARM 体系 结构 中 ， 地 址 空间 分 配 满足 各 种 需求 。 其 中 包括 
加 速 内 核 地 址 换算 (PAGE_OFFSET 到 high. memory - 1) 的 内 存 区 域 owmem， 该 区 域 是 线性 
映射 (linear mapping) XIR; VMALLOC_START 至 VMALLOC END - 1 的 区 域 用 于 离散 页 的 
分 配 ， 可 减少 碎片 ， 增 加 内 存 的 使 用 率 ， 另 外 这 部 分 地 址 空间 在 新 的 内 核 中 还 洱 盖 了 设备 
IO 地 址 空间 (ARM 是 统一 地 址 的 体系 结构 ) ， 设 备 I0 地 址 需要 在 启动 时 在 该 空间 中 保留 一 
部 分 静态 空间 ， 作 为 后 续 的 I0 地 址 映射 使 用 ; 超过 地 址 空间 的 内 存 可 以 通过 定义 HIGH- 
MEM 功能 使 用 ，PKMAP_BASE 至 PAGE_OFFSET -1 的 空间 进行 临时 的 映射 和 使 用 ， 其 他 还 
有 为 设备 特别 保留 的 空间 等 。 可 见 在 整个 地 址 空间 分 配 上 已 经 考虑 得 十 分 周详 。 当 然 上 述 的 
空间 不 都 是 必须 使 用 的 ， 还 是 要 按照 实际 的 需要 进行 配置 ， 通 常情 况 下 ARM 体系 结构 下 的 
地 址 映射 关系 如 图 4-19 所 示 。 
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0xe0000000 VMALLOC END 











vmaloc 用 来 分 配 物理 地 址 


非 连续 空间 VMALLOC START 0 Oxdff 0xc000771c 























VMALLOC OFFSET 0 Oxd01 0xc0007404 
































(8M) : EPE EE 
Oxc1000000 Ee high_memory 0 Oxd00 0xc0007400 
| sm | ET 
[xy x Ox5ff0040e Oxcff 0xc00073fc 
i * ff | | ^ NICO" -— 
E s Suus wur esed 
E = 0x5010040e Oxc01 0xc0007004 
X RLá—————— Á—— e—n—]— [p —ÁheÀ "(À— P — É€— 
Z 0x5000040e Oxc00 0xc0007000 
-text 
€ 
SE 
0xc0008000 | initeowe | tyes Ot, hs 
KERNEL_RAM_VADDR 
pgd(16k) 
swapper. cfr 
0xc0004000 pper. pg. ' 0 Oxbff Oxc0006ffc 
Dc0000000 V RN eror — BEER 
*ko 0 0x001 0xc0004004 
(16M) MODULES  CADDR/ | 一 一 一 一 一 | 
0xb1000000 TASK_SIZE 0 0x000 0xc0004000 














WE: 每 一 个 页 表 项 大 小 为 32bits 
Addr: swapper_pg_cfr+index*4 


图 4-19 ARM 内 核 地 址 空间 映射 关系 


2. 内 核 中 的 映射 实现 和 相关 的 权限 管理 
地 址 映射 的 代码 框架 如 图 4-20 所 示 。 地 址 映射 实际 操作 的 接口 是 创建 页 表 的 create _ 
mapping PRA, ARM (统一 地 址 体系 结构 的 处 理 器 ) 中 无 论 是 内 存 还 是 IO 的 映射 最 终 都 是 
通过 create. mapping 来 实现 的 。 而 iotable_init 则 是 提供 给 处 理 器 的 调用 接口 ， 用 来 进行 IO 空 
间 的 映射 。 
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调用 层 bootmem_init 
xxx map io 
xxx init io 
bootmem init node 
封装 层 map_memory_bank iotable_init 
页 表 创 建 create_mapping 
核心 层 
alloc_init_section a alloc_init_pte 
. pmd populate set pte-ext 





























Fl 4-20 ARM 地 址 映射 代码 框架 








谈 到 create. mapping 的 映射 ， 就 会 涉及 体系 结构 中 不 同 的 访问 方式 和 权限 。 了 解 这些 访 
问 控制 ， 对 于 理解 内 核 的 工作 十 分 有 帮助 。 
首先 来 看 看 create, mapping 的 传人 参数 的 数据 结构 : 





struct map. desc | 
unsigned long virtual ; 
unsigned long pfn; 
unsigned long length; 
unsigned int type; 


E 





该 结构 的 信息 包括 虚拟 地 址 、 物 理 地 址 、 长 度 和 类 型 。 类 型 表示 映射 的 种 类 和 属性 ， 如 
映射 的 是 物理 内 存 还 是 设备 空间 ， 相 应 的 空间 是 否 可 以 共享 或 者 是 否 允 许 Cache 等 。 具 体 的 
定义 在 两 个 文件 中 ， 内 容 如 下 : 








arch/arm/include/asm/io. h 

J * 
* Architecture ioremap implementation. 
*/ 

#define MT DEVICE 

#define MT DEVICE NONSHARED 

#define MT DEVICE CACHED 

#define MT DEVICE WC 


wo NF C 
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arch/arm/include/asm/mach/map. h 

/ * types 0 —3 are defined in asm/io. h * / 
#define MT_UNCACHED 4 
#define MT_CACHECLEAN 

#define MT_MINICLEAN 


#define MT_HIGH_VECTORS 
#define MT_ MEMORY 
#define MT_ROM 10 





5 
6 
#define MT_LOW_VECTORS 7 
8 
9 


系统 中 定义 了 这 么 多 映射 类 型 ， 最 常用 的 是 : MT_MEMORY， 对 应 内 存 映 射 ，MT_DE- 
VICE， 对 应 于 通过 ioremap 的 IO 设备 映射 ， MT_ROM ,对 应 于 ROM; MT. LOW. VECTORS, 
对 应 0 地 址 开始 的 向 量 ; MT_HIGH_VECTORS， 对 应 高 地 址 开始 的 向 量 , 通常 设备 都 是 采用 
高 地 址 映射 。 对 于 向 量 的 映射 是 由 配置 CONFIG_VECTORS_BASE 的 值 来 决定 的 。 

create_mapping 的 调用 必然 通过 这 些 类 型 形成 真正 的 页 表 属 性 才 是 有 意义 的 。 在 相应 的 
内 核 代 码 中 type =&mem_types[ md -> type] ; 来 将 逻辑 的 类 型 转变 为 实际 的 映射 页 表 的 值 。 
相应 的 type 类 型 是 mem_type， 具 体内 容 如 下 : 























struct mem. type | 


E 


unsigned int prot_pte; 
unsigned int prot. 11; 
unsigned int prot, sect ; 


unsigned int domain; 


这 里 的 值 都 是 和 访问 权限 、 属 性 相关 的 ， 要 了 解 详 细 的 内 容 就 需要 从 ARM 相关 的 设计 


开始 入 手 。 首 先 ， 


Fault 


Page table 


Section 


Supersection 


Reserved 











看 看 两 级 页 表 项 的 内 容 ， 分 别 如 图 4-21 和 图 4-22 所 示 。 

























































































31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 19 | 18 | 17 16 is | 4 13 | 12 n | 10 9 8 7 | 6 5 4 | 3 2 1 0 
Ignored 0/0 
Level 2 Descriptor Base Address P Domain SBZ 0,1 

E n A x 
Section Base Address B|0 G S| TEX AP | P Domain N C/Bi|1/0 

Zz X 

Supersorton SBZ "]s]e| tex | ae |P] Doman |xlclelilo 

Base Address G x N 
1-13] 














图 4-21 ARM 一 级 页 表 


一 级 页 表 和 二 级 页 表 都 会 根据 后 两 位 有 不 同 的 映射 形式 。Linux 内 核 会 针对 之 前 提 到 的 
不 同类 型 采用 合适 的 形式 进行 映射 ， 一 级 页 表 存 放 在 swapper_pg_dir 开始 的 16 KB 区 域内 ， 
在 映射 空间 不 满 1 MB 的 情况 下 才 使 用 二 级 页 表 。 对 1 MB 空间 采用 section 方式 的 只 需要 一 


次 转换 即 可 。 
通过 页 表 建 立 的 映射 关系 如 图 4-23 所 示 。 
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31 | 30 | 29 | 28 | 27 26 | 25 | 24 23 | 22 | 21 20 | 9 18 17 | 16 15 | 12] 11 | 10) 9 s |7 6 s|4 3/2]1[|0 
Fault Ignored 0/0 
x n A 
Large page Large Page Base Address N TEX G SP SBZ APS IC Ba O1 
x 
n A x 
Small page Small Page Base Address G SP SBZ AP |C|B|1 N 
X 
图 4-22 ARM 二 级 页 表 
Level one fetch Level two fetch 
Translation section 
table 
TTB base Invalid 
00 
Indexed by 
modified Section base 
virtual 10 1MB 
address bits 
[31:20] Indexed by Large page 
01 modified L b 
virtual arge page base 
address 16KB subpage 
bits [19:0] Indexed by 
11 modified virtual 16KB subpage 
address bits 
Coarse page table [15:0] 
Coarse page 16KB subpage 
À taljle base Invalid 
4096 entries 00 
16KB subpage 
Indexed b 
modified 01 SAP 
virtual 
address 
bits [19:14] ai Small page base Small page 
1KB subpage 
vei Indexed by 
nval modified virtual 
a — address bits 1KB subpage 
[11:0] 
256 entries 1KB subpage 
Fine page table 1KB subpage 
Fine pago Invalid 
table base 00 4KB 
Indexed 
by 
modified Di 
virtual 
address 
bits 10 r 
[19:10] Tiny page 
Tiny page base 
11 
Indexed by 
modified 
virtual 1 KB 
1024 entries address bits 
[9:0] 


图 4-23 ARM 页 表 的 映射 关系 
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接 下 来 对 权限 进行 详细 的 说 明 ， 页 表 设 置 中 访问 权限 相关 的 域 分 别 为 Domain, AP 和 
APX。 这 里 的 Domain 是 一 个 索引 值 ， 具 体 每 个 Domain 的 权限 是 由 CP15 的 C3 寄存 器 中 的 每 
两 位 来 设 定 的 。 权 限 的 具体 内 容 见 表 4-2。 


表 4-2 Domain 权限 具体 内 容 


















































值 访问 类 型 fe X 

0b00 无 访问 权限 此 时 访问 该 域 将 产生 访问 失效 

T 用 户 根据 CP15 的 C1 控制 寄存 器 中 的 R 和 S 位 以 及 页 表 中 地 址 变换 条 目 中 的 访问 权限 控制 位 
(client) AP 来 确定 是 否 人 允许 各 种 系统 工作 模式 的 存储 访问 

0b10 保留 使 用 该 值 会 产生 不 可 预知 的 结果 

ini 管理 者 不 考虑 CP15 的 CI 控制 寄存 器 中 的 R 和 S 位 以 及 页 表 中 地 址 变换 条 目 中 的 访问 权限 控制 位 
(Manager) AP， 在 这 种 情况 下 ， 不 管 系统 工作 在 特权 模式 ， 还 是 用 户 模式 ， 都 不 会 产生 访问 失效 














Linux 内 核 只 是 用 了 几 个 Domain， 对 应 的 权限 值 定 义 在 arch/arm/include/asm/domain. h 
中 ， 具 体内 容 如 下 : 


AP 和 APX 的 


#define DOMAIN_KERNEL 
#define DOMAIN_TABLE 
#define DOMAIN_USER 
#define DOMAIN_IO 


y= Ss S&S 


#define DOMAIN_NOACCESS 0 
#define DOMAIN_CLIENT 1 
#define DOMAIN MANAGER 3 











属性 说 明 见 表 4-3。 





通常 使 用 APX =0 进行 设置 。 


表 4-3 访问 权限 属性 说 明 















































APX AP[1:0] 特权 模式 访问 权限 用 户 模式 访问 权限 

0 00 禁止 访问 ; S=1, R=0 RS=0, R=1 时 只 读 禁止 访问 ; S=1，R =0 时 只 读 
0 01 读 写 禁止 访问 

0 10 读 写 只 读 

0 11 读 写 读 写 

1 00 保留 保留 

1 01 只 读 禁止 访问 

1 10 只 读 只 读 

1 11 只 读 只 读 

















回头 看 看 mem, type 中 的 几 个 域 现在 就 清楚 了 , prot. pte 是 二 级 页 表 的 访问 控制 属性 ,prot_ 


l1 是 有 二 级 页 表情 况 下 的 一 级 页 表 访 问 控制 B, prot_sect 是 一 级 页 表 section 模式 访 问 控制 





TE, domain 代表 一 级 页 表 访 问 属性 中 的 
Linux 内 核 中 页 表 属 性 的 位 域 定义 在 arch/arm/include/asm/pgtable-hwdef. h 中 具体 如 下 : 
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Hl 


Domain ,会 根据 需要 填 和 人 到 prot_ll 或 者 prot, sect 中 。 


#define PMD_TYPE_TABLE (1 <<0) 
#define PMD_TYPE_SECT (2 <<0) 
#define PMD_BIT4 (1 <<4) 
#define PMD_DOMAIN(x) ((x) «5) 
#define PMD SECT AP. WRITE (1 ««10) 
#define PMD SECT AP. READ (1 <<11) 








由 于 domain 在 访问 权限 判断 中 优先 级 高 ， 所 以 它 的 设置 就 显得 比较 重要 ，Linux 对 不 同 
domain 设置 的 相关 代码 如 下 : 














arch/arm/include/asm/domain. h 
#define domain_val( dom, type ) ( (type) << (2 * (dom) ) ) 


#define set_domain(x) \ 
do | \ 
. asm volatile ( \ 
"mer p15, 0, 960, c3, c0 @ set domain" — V 
g "a" (sy \ 
isb() ; \ 
| while(0) 
#define modify_domain( dom, type ) \ 
do | \ 
struct thread. info * thread = current, thread, info( ) ; \ 
unsigned int domain = thread —» cpu, domain; \ 
domain & = ~ domain, val( dom, DOMAIN, MANAGER) ; \ 
thread —» cpu, domain = domain | domain_val(dom, type) ; \ 
set, domain( thread —» cpu, domain) ; \ 
| while(0) 


arch/arm/kernel/head. S 


mov 15, #(domain_val( DOMAIN, USER, DOMAIN, MANAGER) | \ 
domain val( DOMAIN. KERNEL, DOMAIN MANAGER) | \ 
domain, val( DOMAIN, TABLE, DOMAIN, MANAGER) | \ 
domain, val( DOMAIN. IO, DOMAIN. CLIENT) ) 


mcr p15, 0, 15, c3, c0, 0 @ load domain access register 
mcr pl5, 0, 14, c2, c0, 0 @ load page table pointer 
b . turn mmu, on 


ENDPROC( enable mmu) 
可 见 ， 内 核 在 启动 的 初期 就 对 这 三 个 域 的 访问 控制 进行 了 设置 。 这 里 的 设置 主要 是 因为 
系统 在 内 核 态 拥有 特权 级 别 ， 这 样 的 设置 可 以 减少 权限 检测 。 但 这 个 设置 并 不 是 一 成 不 变 
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的 ， 内 核 提 供 了 modify domain 的 宏 ， 作 为 修改 域 访 问 控制 位 的 接口 。 内 核 在 setup_arch 中 
调用 early_trap_init， 利 用 该 接口 将 DOMAIN, USER 的 权限 位 设置 成 DOMAIN. CLIENT, 354} 
对 于 DOMAIN KERNEL 同样 需要 在 内 核 执 行 用 户 态 任务 之 前 将 其 设置 为 DOMAIN, CLIENT, 
这 样 才 能 进行 访问 权限 的 检查 。 对 于 DOMAIN_KERNEL 的 修改 会 通过 set_fs 接口 来 执行 ， 
这 主要 是 因为 系统 调用 ， 特 别 是 文件 系统 的 操作 ， 经 党 会 调用 内 核 空间 执行 相应 系统 调用 的 
接口 ， 这 些 接口 是 与 体系 结构 无 关 的 ， 所 以 要 进行 地 址 检查 ， 确 保 操作 的 数据 来 自用 户 空间 
而 不 是 内 核 空 间 ， 如 果 从 内 核 直接 调用 就 会 报告 异常 。 这 时 候 的 解决 方案 就 是 临时 提高 权 
限 ， 等 操作 完成 后 再 恢复 原 有 的 权限 ， 这 样 就 有 set. fs 接口 。ARM 体系 结构 中 ， 由 于 有 ldrt 
(无 论处 理 器 当前 的 权限 级 别 都 以 用 户 级 权限 执行 ) 指令 ， 像 get_user 这 种 获得 用 户 数据 的 
操作 ， 自 然 用 ldrt 更 合理 。 这 样 对 前 述 的 内 核 态 参数 的 访问 ， 使 用 ldrt 时 会 有 同样 问题 ， 所 
以 在 ARM 体系 结构 下 ， 会 将 体系 结构 无 关 的 权限 升级 与 DOMAIN_KERNEL 的 权限 升级 结合 
到 一 起 。 当 然 平时 都 是 在 DOMAIN_CLIENT 的 状态 下 进行 权限 检查 的 。 另 外 在 任务 切换 时 同 
样 需要 进行 domain 权限 的 转换 ， 这 就 由 thread_info 中 的 epu, domain 域 记录 并 完成 。 这 样 就 
对 整个 系统 任何 时 候 都 进行 了 合适 的 domain 值 的 设置 。 做 这 么 多 的 工作 都 是 因为 映射 本 身 
涉及 权限 ， 权 限 是 和 安全 相关 的 ， 所 以 要 格外 的 小 心 ， 哪 怕 花 费 精力 也 是 必要 的 。 

内 核 中 各 种 映射 类 型 及 访问 权限 相关 的 设置 见 表 4-4。 

表 4-4 ”映射 类 型 和 访问 权限 设置 
内 存 映 射 类 型 域 定义 段 页 表 项 权限 定义 |L 页 表 项 权限 定义 PTE 项 权限 定义 


PROT_PTE_DEVICE 
MT_DEVICE DOMAIN_IO PROP T-DEVICE PMD TYPE TABLE |L PTE MT DEV SHARED 


PMD_SECT_S L_PTE_SHARED 























PROT_PTE_DEVICE 





MT_DEVICE_NONSHARED | DOMAIN_IO PROT_SECT_DEVICE PMD_TYPE_TABLE L PTE MT. DEV. NONSHARED 
PROT SECT DEVICE PROT PTE DEVICE 
MT DEVICE CACHED DOMAIN IO PMD SECT WB PMD TYPE TABLE L PTE MT. DEV. CACHED 











ROT PTE DEVICE 


MT DEVICE WC DOMAIN IO PROT SECT DEVICE PMD TYPE TABLE L PTE MT DEV. WC 














PMD TYPE SECT 
MT UNCACHED DOMAIN IO MD SECT. XN PMD TYPE TABLE |PROT PTE DEVICE 


= 





MD_TYPE_SECT 


MT_CACHECLEAN DOMAIN_KERNEL MD. SECT. XN 














MT MINICLEAN DOMAIN, KERNEL |PMD SECT XN 


MD SECT MINICACHE, 





P 
P 
PMD_TYPE_SECT 
P 
P 





L_PTE_PRESENT 
L_PTE_YOUNG 
L_PTE_DIRTY 
L_PTE_EXEC 


MT_LOW_VECTORS DOMAIN_USER PMD_TYPE_TABLE 





L_PTE_PRESENT 
L_PTE_YOUNG 
MT_HIGH_VECTORS DOMAIN_USER PMD_TYPE_TABLE |L_PTE_DIRTY 
L_PTE_USER 
L_PTE_EXEC 
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(E) 
内 存 映射 类 型 域 定义 股 页 表 项 权限 定义 | LI 页 表 项 权限 定义 PTE 项 权限 定义 
PMD_TYPE_SECT 




















MT. MEMORY DOMAIN. KERNEL 
PMD SECT AP WRITE 
MT. ROM DOMAIN, KERNEL | PMD TYPE. SECT 
这 样 整个 ARM 体系 结构 的 映射 框架 就 比较 清晰 了 。 
3. 总 结 


Linux 内 核 ARM 体系 结构 下 整个 空间 映射 的 数据 和 权限 的 特点 为 Linux 在 ARM 体系 结 
构 下 通常 是 使 用 4KB 大 小 的 页 ， 但 是 对 于 线性 映射 的 内 核 空 间 (low memory) 以 及 IO 空间 
使 用 1MB 大 小 的 页 。 内 核 针 对 不 同 的 应 用 场景 一 共有 六 种 不 同类 型 页 映射 ， 分 别 如 下 : 
e 对 于 存放 应 用 或 共享 库 代 码 的 页 面 ， 映 射 时 会 标记 为 只 读 ， 并 且 人 允许 映射 到 多 个 应 用 
的 地 址 空间 。 
e 对 于 保护 可 写 数据 的 页 面 要 标记 XN 位 表示 不 可 执行 ， 用 于 捕获 试图 执行 数据 区 的 错误 。 
e 对 于 用 户 用 来 映射 普通 文件 的 页 面 、 包 仿 stack 或 者 heap 的 页 面 、kernel modules 使 用 
的 页 面 、 内 核 线性 映射 的 页 面 以 及 vmalloe 空间 的 页 面 都 被 标记 为 “normal，cache- 
able”, MEA stack 或 者 heap 的 页 面 在 初始 分 配 时 设计 成 会 引发 缺 页 异常 的 只 读 零 
页 ， 只 有 在 首次 写 数据 引发 的 缺 页 异常 中 才 进 行 真 正 的 分 配 操作 。 注 意 所 有 的 页 表 项 
都 是 通过 内 核 的 线性 映射 空间 进行 分 配 的 。 
e 包含 设备 文件 映射 的 页 面 由 设备 驱动 负责 映射 。 
e 包含 异常 向 量 表 的 页 面 被 标记 为 normal cacheable 并 且 用 户 态 只 读 。 
© 内 核 中 静态 和 动态 映射 的 设备 存储 区 域 需要 设置 为 用 户 态 不 能 访问 。 
熟悉 这 些 类 型 对 于 理解 内 存 管理 是 很 有 帮助 的 ， 因 为 这 些 类 型 也 是 内 存 页 面 使 用 的 不 同方 式 。 


4.2.3 TI 芯片 地 址 映射 相关 实现 详解 


1. 芯片 相关 的 内 核 地 址 空间 分 配 和 映射 

现在 看 看 具体 芯片 在 地 址 映射 这 部 分 是 如 何 实现 的 。 内 存 部 分 的 映射 完全 可 以 通过 启动 
参数 以 及 一 些 安定 义 实现 。 通 过 mem 和 vmalloc 这 两 个 内 核 提 供 的 启动 参数 以 及 VMALLOC _ 
START 和 VMALLOC_END 两 个 宏 ， 可 以 将 lowmem 和 vmalloc 的 空间 定 下 来 。 相 关 的 宏 定 义 
DM 3730 和 DM 816X 的 内 核 代码 如 下 : 























arch/arm/plat — omap/include/mach/vmalloc. h 
#define VMALLOC END  0xf8000000UL 


arch/arm/include/asm/pgtable. h 

#ifndef VMALLOC. START 

#define VMALLOC, OFFSET (8 * 1024 * 1024) 

#define VMALLOC, START ( ( (unsigned long) high. memory + VMALLOC, OFFSET) & ~ ( VMAL- 
LOC. OFFSET - 1) ) 

#endif 





vmalloc 的 空间 是 在 lowmem 之 后 的 8 MB 开始 的 ， 当 然 vmalloc 的 空间 不 是 随意 大 小 的 ， 
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会 有 最 小 空间 的 限制 ， 默 认 限 制 如 下 : 
static void * _ initdata vmalloc_min = (void * )(VMALLOC_END -SZ_128M ) ; 


当然 相应 的 大 小 可 以 由 启动 参数 vmalloc 进行 设置 ， 但 是 也 不 能 小 于 16 MB。 有 了 总 的 
内 存 设置 (启动 参数 mem) ， 有 了 vmalloc 2 [RIZ aan a 间 限 制 ， 内 存 的 映射 基 
本 就 解决 了 。 如 果 内 存 容 量 超出 了 这 些 空间 ， 还 有 pkmap 可 以 进行 映射 。 当 然 之 前 说 明 新 
的 内 核 中 (DM 3730 和 DM 816X 没有 相应 版 本 的 实现 ) VMALLOC, END 已 经 直接 由 ARM 
A 投 定 为 0xff000000 了 ， 这 样 的 调整 对 于 实现 没有 太 大 的 影响 ， 因 为 这 是 地 址 空间 的 调 

具体 映射 的 内 容 可 以 在 映射 模块 内 部 解决 兼容 性 的 问题 。 

2. IO 空间 在 内 核 中 的 映射 

接 下 来 的 重点 是 10 空间 的 映射 。 首 先 ， 来 看 看 DM 3730 的 物理 空间 是 如 何 设置 的 ， 如 
图 4-24 所 示 。 图 4-24 引 自 《DM 3730 芯片 手册 》 中 第 204 页 的 表 ， 由 于 表 比 较 大 ， 这 里 只 
截取 一 部 分 。 




























































































Quarter Device Name Start Address End Address Size Description 
(Hex) (Hex) 
Qo Boot space'" 1MB 
(1GB) GPMC 1GB 
or 1GB-1MB 
GPMC Ox0000 0000 Ox3FFF FFFF 1GB 8/16 Ex "'IRIW 
ai On-chip memory 128MB ROM/SRAM address space 
(1GB) 
Ox4000 0000 0x4001 3FFF BOKB Reserved for boat code 
Boot ROM Not accessible after boot 
internal!!! 7 
Ox4001 4000 Ox4001 BFFF 32KB 32-bit Ex "'/R 
Reserved Ox4001 C000 Ox400F FFFF 912KB Reserved 
Reserved 0x4010 0000 0x401F FFFF 1MB Reserved 
SRAM internal Ox4020 0000 0x4020 FFFF 64KB 32-bit Ex "'TRW. 
Reserved 0x4021 0000 Dx4024 FFFF 256KB Reserved 
Reserved 0x4025 0000 Ox47FF FFFF 128,704KB Reserved 
L4 interconnects 128MB All system peripherals 
L4-Core 0x4800 0000 Ox48FF FFFF 16MB See Table 2-3. 
(L4-Wakeup)?! (0x4830 0000) (0x4833 FFFF) (256KB) ^ See Table 2-4. 
L4-Per 0x4900 0000 0x490F FFFF 1MB See Table 2-5. 
Reserved 0x4910 0000 Ox4FFF FFFF 111MB Reserved 
SGX 64MB Graphic accelerator slave 
port 
SGX 0x5000 0000 0x5000 FFFF 64KB Graphic accelerator slave port 
Reserved 0x5001 0000 OxS3FF FFFF 65,472KB Reserved 
L4 emulation 64MB Emulation 
L4-Emu 0x5400 0000 0x547F FFFF BMB See Table 2-6. 
Reserved 0x5480 0000 OxS7FF FFFF 56MB Reserved 
Reserved 64MB Reserved 
Reserved 0x5800 0000 OxSBFF OFFF 64MB Reserved 
IVA2.2 64MB 1VA2.2 subsystem 
subsystem 
IVA2.2 Ox5C00 0000 OxSEFF FFFF 48MB IVA2.2 subsystem. See 
subsystem Table 2-8. 
Reserved 0x5F00 0000 OxSFFF FFFF 16MB Reserved 
Reserved 128MB Reserved 
Reserved Dx6000 0000 Ox67FF FFFF 128MB Reserved 
L3 interconnect 128MB Control registers 
L3 control 0x6800 0000 Ox68FF FFFF 16MB See Table 2-2. 
registers 
Reserved 0x6900 0000 Ox6BFF FFFF 48MB Reserved 
SMS registers 0x6C00 0000 Ox6CFF FFFF 16MB Configuration registers SMS 
address space 2 
SDRC registers 0x6D00 0000 Ox6DFF FFFF 16MB Configuration registers SMS 
address space 3 
GPMC registers 0x6E00 0000 Ox6EFF FFFF 16MB Configuration registers GPMC 
address space 1 
Reserved Ox6F00 0000 Ox6FFF FFFF 16MB Reserved 
SDRC/SMS 256MB SDRC/SMS 











Al 4-24 DM 3730 物理 空间 设置 
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IO 空间 映射 的 目的 就 是 将 这 些 物 理 地 址 映射 到 整个 内 核 的 地 址 空间 中 。 下 面 来 看 看 DM 
3730 内 核 中 映射 关系 是 怎样 的 。 在 arch/arm/plat- omap/include/mach/io. h 中 定义 映射 关系 
如 下 : 











* Omap3 specific IO mapping 





*/ 


/** We map both L3 and L4 on OMAP3 */ 

#define L3. 34XX PHYS L3 34XX BASE/ * 0x68000000 ——»0xf8000000 */ 
#define L3 34XX. VIRT (L3. 34XX PHYS + OMAP2 I3 IO OFFSET) 

#define L3. 34XX, SIZE SZ 1M /x 44kB of 128MB used, want 1 MB sect */ 


#define I4 34XX, PHYS 14_34XX_BASE/ * 0x48000000 —-—»0xfa000000 */ 
#define L4_34XX_VIRT (14_34XX_PHYS + OMAP2_I4_IO_OFFSET) 
#define L4_34XX_SIZE SZ_4M /x 1MB of 128MB used, want 1MB sect */ 


J * 
* Need to look at the Size 4M for LA. 
* VPOM3430 was not working for Int controller 
*/ 


"define L4. PER. 34XX PHYS I4 PER 34XX BASE 

/ * 0x49000000 ——20xfb000000 * / 
#define L4. PER. 34XX. VIRT (I4 PER 34XX PHYS + OMAP2 IA IO OFFSET) 
#define L4. PER. 34XX. SIZE SZ 1M 


#define L4. EMU 34XX PHYS I4 EMU 34XX BASE 

/ * 0x54000000 --> 0xfe800000 * / 
#define L4. EMU. 34XX. VIRT (LA EMU 34XX PHYS + OMAP2 EMU IO OFFSET) 
#define L4. EMU. 34XX SIZE SZ 8M 


#define OMAP34XX GPMC PHYSOMAP34XX GPMC BASE 

/** 0x6e000000 ——»O0xfe000000 */ 

#define OMAP34XX GPMC VIRT (OMAP34XX GPMC PHYS + OMAP2 L3 IO OFFSET) 
#define OMAP34XX GPMC SIZE SZ 1M 


#define OMAP343X SMS PHYSOMAP343X SMS BASE 
/** 0x6c000000 ——»0xfe000000 */ 
#define OMAP343X SMS VIRT(OMAP343X, SMS PHYS + OMAP2 I3 IO OFFSET) 
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#define OMAP343X SMS SIZESZ 1M 


#define OMAP343X SDRC PHYSOMAP343X SDRC BASE 

/ * 0x6D000000 ——20xfd000000 * / 

#define OMAP343X SDRC VIRT ( OMAP343 X_SDRC_PHYS + OMAP2 I3 IO OFFSET) 
#define OMAP343X SDRC SIZE SZ 1M 





/ * 3430 IVA — currently unmapped * / 


可 见 映 射 是 从 0xf8000000 开始 的 ， 正 好 是 在 vmalloc Za, ERARA ZS TR] CERES [8] 

。 从 物理 地 址 的 角度 和 图 4-24 中 描述 的 地 址 也 是 吻合 的 ， 只 是 代码 中 每 部 分 的 空间 只 
TERN 不 像 物理 上 预 留 了 更 多 的 空间 。 

有 了 这 样 的 映射 关系 之 后 ， 就 要 解决 两 个 问题 : 一 个 是 ioremap 如 何 返 回 正确 的 虚拟 地 
址 ;另外 一 个 就 是 实际 的 映射 建立 。 

首先 来 看 ioremap 虚拟 地 址 返回 是 如 何 实现 的 。 在 ARM 的 io. h 中 有 如 下 和 定义: 














#ifndef — arch_ioremap 


#define — arch ioremap . arm, ioremap 

"define — arch. iounmap .. jounmap 

#endif 

#define ioremap( cookie , size ) . arch ioremap( ( cookie) , (size) , MT DEVICE) 

#define ioremap nocache(cookie,size) ^ arch ioremap( (cookie) , (size) , MT DEVICE) 

#define ioremap cached( cookie,size) ^ ^ arch ioremap( (cookie) , (size), MT DEVICE CACHED) 
#define ioremap. wc( cookie, size ) .. arch, ioremap( (cookie) , (size) , MT DEVICE WC) 
#define iounmap . arch, iounmap 


可 见 ， 可 以 通过 定义 特别 的 arch_ioremap 来 实现 ioremap 的 重 定 向 。DM 3730 $E TI 世 
片 就 是 通过 该 方法 来 实现 该 功能 的 。 下 面 来 看 看 细节 ， 在 arch/arm/plat - omap/include/ 
mach/io. h 中 有 如 下 定义 : 








#define — arch_ioremapomap_ioremap 


#define — arch. iounmapomap. iounmap 


最 终 由 omap_ioremap 来 实现 ioremap 的 功能 看 看 omap_ioremap 的 代码 就 清楚 了 é 代码 
如 下 : 


void _ iomem * omap_ioremap( unsigned long p, size_t size, unsigned int type) 


| 


#ifdef CONFIG. ARCH, OMAP3 
if( epu. is. omap34xx( ) ) | 
if( BETWEEN( p, L3. 34XX. PHYS, I3, 34XX. SIZE) ) 
return XLATE(p, 13. 34XX. PHYS, I3. 34XX. VIRT) ; 
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if( BETWEEN( p, L4_34XX_PHYS, I4 34XX SIZE) ) 
return XLATE( p, I4. 34XX, PHYS, I4. 34XX, VIRT) ; 
if( BETWEEN( p, OMAP34XX. GPMC, PHYS, OMAP34XX, GPMC, SIZE) ) 
return XLATE( p, OMAP34XX, GPMC, PHYS, OMAP34XX_GPMC_VIRT) ; 
if( BETWEEN( p, OMAP343X. SMS PHYS, OMAP343X_SMS SIZE) ) 
return XLATE( p, OMAP343X. SMS. PHYS, OMAP343X, SMS, VIRT) ; 
if( BETWEEN( p, OMAP343X, SDRC, PHYS, OMAP343X. SDRC SIZE) ) 
return XLATE( p, OMAP343X. SDRC. PHYS, OMAP343X_SDRC_VIRT) ; 
if( BETWEEN( p, I4. PER. 34XX. PHYS, I4. PER, 34XX, SIZE) ) 
return XLATE( p, L4. PER. 34XX, PHYS, I4. PER 34XX, VIRT) ; 
if( BETWEEN(p, L4 EMU 34XX. PHYS, I4 EMU 34XX SIZE) ) 
return XLATE( p, L4 EMU 34XX. PHYS, I4. EMU 34XX VIRT) ; 








| 
#endif 


#ifdef CONFIG_ARCH_TI81XX 
if( cpu_is_ti81xx() ) | 
if( BETWEEN(p, L4 SLOW TISIXX PHYS, L4_SLOW_TI81XX_SIZE) ) 
return XLATE(p, [4_SLOW_TI81XX_PHYS, [4_SLOW_TI81XX_VIRT) ; 
if BETWEEN(p, TI81XX_L2_MC_PHYS, TISIXX I2 MC SIZE)) 
return XLATE(p, TISIXX L2 MC PHYS, TI8IXX I2 MC VIRT); 
| 
#endif 


return arm ioremap caller(p, size, type, __ builtin_return_address(0) ) ; 


| 














其 中 所 做 的 工作 就 是 ， 如 果 是 映射 关系 中 的 物理 地 址 就 直接 转换 为 相应 的 虚拟 地 址 并 返 
回 ， 和 否则 就 使 用 ARM 内 核 提 供 的 _arm_ioremap_caller 进行 映射 。 注 意 arm_ioremap_caller 
使 用 的 是 vmalloc 的 空间 进行 映射 ， 在 相应 版 本 内 核 中 vmalloe 的 空间 和 TL 芯片 的 10 映射 
间 是 完全 分 开 的 ， 所 以 这 里 要 直接 返回 相应 的 虚拟 地 址 。 新 内 核 的 iotable_init 是 通过 vmal- 
loc 空间 的 静态 分 配 来 将 这 部 分 地 址 在 初始 化 的 时 候 保 留 ， 这 样 就 可 以 直接 使 用 ARM 内 核 的 
ioremap 而 不 需要 进行 重 定向 了 。 新 内 核 的 该 功能 进一步 减少 了 不 同 处 理 带 之 间 的 差别 ， 减 
少 了 移植 的 工作 量 。 

具体 映射 的 建立 则 是 从 板 级 相关 的 初始 化 接口 map. io 开始 。 对 于 DM 3730 相应 的 map_ 
io 为 omap3_map_io， 其 内 容 如 下 : 























void X init omap3_map_io( void) 
| 
omap2_set_globals_3xxx( ) ; 


omap34xx map. common io( ) ; 
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重点 是 在 omap34xx_map_common_io 中 ， 该 函数 及 相关 函数 详细 说 明 。 其 代码 如 下 : 





void __ init omap34xx map. common. io( void) 

| 
// 设 置 相应 的 10 Ai FFAS TAY memory 地 址 的 页 表 
//io_desc 是 根据 芯片 手册 的 memory map 表 定 义 的 ,占用 尽量 少 的 空间 
iotable_init( omap34xx_io_desc, ARRAY_SIZE( omap34xx_io_desc) ) ; 








/该 因数 根据 chip type 设 定 相 关 的 特性 flag ,并 初始 化 片 内 sram 


omap2_map_common_io( ) ; 








| 


// 本 函数 检查 omap chip 的 版 本 特性 ,并 进行 internal sram 的 初始 化 
// 包 括 根据 omap chip 的 type 设置 sram 地 址 及 kernel 的 内 部 映射 
static void __ init _omap2_map_common_io( void) 


| 





/ * Normally devicemaps. init( ) would flush caches and tlb after 
* mdesc —» map, io( ) , but we must also do it here because of the CPU 
* revision check below. 
*/ 
// 通 常 devicemaps init 在 调用 machine, desc 的 map. io 之 后 都 会 flush tlb 和 cache。 此 处 在 map. io 
// 内 部 由 于 需要 访问 寄存 带 , 为 保险 flush 一 下 
local_flush_tlb_all( ) ; 
flush, cache, all( ) ; 


omap2, check, revision( ) ; 


// 初 始 化 on — chip sram 
omap_sram_init( ) ; 


| 


10 空间 页 表 的 映射 是 通过 ARM 内 核 提 供 的 iotable_init 实现 的 。 映 射 之 后 就 进行 寄存 髓 
的 访问 以 及 片 内 RAM 的 初始 化 ， 片 内 RAM 的 初始 化 由 于 和 内 存 管理 相关 ， 还 是 放 在 内 存 
管理 的 实现 中 进行 说 明 。 而 对 于 具体 的 映射 属性 是 通过 omap34xx_io_desc 数组 定义 的 ， 具体 
的 数组 内 容 可 以 通过 实际 代码 来 了 解 细节 。 














4.3 中 断 处 理 


中 断 是 指 硬件 停止 当前 正在 运行 的 程序 ， 将 系统 转向 处 理 其 他 工作 的 能 力 。 中 断 作 为 一 
种 技术 在 处 理 器 实现 后 就 完全 改变 了 整个 系统 的 编程 方式 ， 为 系统 带 来 了 外 部 事件 。 不 要 小 
看 这 些 外 部 事件 ， 从 系统 论 的 角度 ， 一 个 系统 只 有 不 断 有 新 鲜 事 物 的 进入 才能 得 到 发 展 ， 所 
请 “流水 不 腐 户 枢 不 宪 ”。 虽 然 中 断 带 来 的 外 部 事件 和 新 鲜 事物 无 法 同日 而 语 ， 但 是 中 断 可 
以 说 是 计算 机 系统 的 一 次 革命 ， 给 计算 机 系统 带 来 了 无 限 可 能 。 
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4.3.1 中 断 的 基本 需求 


对 于 中 断 系 统 的 需求 ， 首 先 要 看 看 中 断 在 系统 中 的 硬件 连接 是 怎么 样 的 ， 如 图 4-25 
所 示 。 
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图 4-25 ”中断 在 系统 中 的 连接 示意 图 





从 图 4-25 中 可 见 ， 中 断 相 关 的 硬件 包括 设备 、 中 断 控 制 器 和 处 理 器 。 处 理 器 是 和 系统 
结构 相关 的 ， 剩 下 的 设备 和 中 断 控制 器 可 能 有 各 种 不 同 的 实现 ， 所 以 中 断 处 理 框 架 需 要 能 
适应 各 种 设备 和 中 断 控制 器 的 实现 。 在 SMP 的 系统 中 ， 中 断 处 理应 该 可 以 在 任何 或 者 指定 
的 处 理 上 执行 ， 中 断 处 理 框 架 应 该 支持 该 功能 。 

另外 ， 中 断 可 以 通过 中 断 控制 器 进行 级 联 ， 如 图 4-26 所 示 。 
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图 4-26 中 断 在 系统 中 级 联 示 意图 








从 图 4-26 中 可 见 ， 中 断 控制 器 也 可 以 分 层次 ， 而 和 CPU 最 近 的 中 断 控 制 器 可 以 作为 主 


137 


中 断 控制 器 。 这 种 情况 下 ， 主 中 断 控制 器 中 就 有 某 些 中 断 只 是 作为 级 联 使 用 ， 而 处 理 器 要 
够 区 分 其 他 中 晰 控制 咒 上 报 的 中 断 究竟 来 自 哪 个 设备 ， 并 对 中 晰 控制 器 进行 正确 的 操作 。 民 
了 级 联 之 外 还 可 能 有 多 个 设备 共享 同一 个 中 断 ( 如 PCI 总 线 设备 ) ， 这 就 要 求 中 断 处 理 框 
也 要 支持 多 个 设备 共享 中 断 的 功能 。 

从 中 断 触发 信号 的 角度 ， 不 能 限制 中 断 触 发 的 形式 ， 所 以 中 断 处 理 框 架 还 需要 支持 不 同 
的 中 断 触 发 方式 。 触 发 信号 的 方式 不 同 ， 带 来 的 处 理 逻 辑 也 是 不 同 的 ， 比 如 边沿 触发 信号 就 
不 会 产生 假 中 断 的 问题 ， 而 电 平 触发 则 会 有 假 中 断 的 问题 。 这 需要 对 中 断 控制 右 进 行 不 同 的 
操作 逻辑 来 避免 该 类 问题 的 发 生 ， 中 断 处 理 惕 辑 需要 和 中 断 控 制 融 的 操作 相 结 合 以 使 中 断 处 
理 能 正确 的 执行 。 

以 上 主要 还 是 功能 需求 ， 对 于 性 能 方面 ， 中 断 处 理 都 是 有 时 间 要 求 的， 所 以 会 有 中 断 响 
应 时 间 这 一 性 能 指标 的 要 求 。 好 的 系统 需要 在 大 量 上 报 中 断 时 仍 能 有 较 小 的 中 断 响应 时 间 。 
而 设备 的 差别 ， 造 成 在 中 断 处 理 中 需要 处 理 的 数据 量 是 有 差异 的 ， 不 能 因为 某 些 设备 有 大 
量 数据 需要 处 理 就 影响 其 他 设备 的 中 断 响应 时 间 ， 所 以 在 中 断 处 理 框架 中 也 要 考虑 这 种 
能 的 需求 。 
4.3.2 中 断 处 理 框架 介绍 

1. 基本 中 断 处 理 流 程 

Linux 内 核 的 中 断 处 理 框架 当然 要 满足 之 前 提 到 的 各 种 需求 。 对 Linux 内 核 来 说 ， 每 个 
中 断 号 都 是 通过 irq_dese 进行 描述 的 ， 可 以 说 irq_desc 是 中 断 处 理 的 核心 。 下 面 来 看 看 相应 
的 内 容 : 
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im: 








struct irq- desc | 
Ie 
* This union will go away, once we fixed the direct access to 
* irq desc all over the place. The direct fields are a 1:1 
* overlay of irq- data. 
*/ 
// 这 里 union 是 历史 遗留 问题 ,irq_data 和 下 面 的 struct 内 容 完全 相同 ,需要 等 到 所 有 中 断 
// 处 理 代码 都 使 用 irq_data 后 ,该 struct 才 会 被 移 除 















































union | 
struct irq_data irq_data; 
struct | 
unsigned int irq; 
unsigned int node; 
struct irq_chip * chip; 
void * handler_data; 
void * chip_data; 
struct msi_desc * msi_desc; 
#ifdef CONFIG_SMP 
cpumask_var_t affinity ; 
#endif 


138 


E 
F 
#endif 


struct timer_rand_state * timer_rand_state; 
unsigned int * kstat_irqs; 


irq_flow_handler_thandle_irq; 





struct irqaction * action; / * IRQ action list */ 

unsigned int status ; /* IRQ status * / 

unsigned int depth; / * nested irq disables * / 

unsigned int wake_depth; / * nested wake enables * / 

unsigned int irq_count; / * For detecting broken IRQs */ 
unsigned long last_unhandled; / * Aging timer for unhandled count * / 
unsigned int irqs_unhandled; 

raw_spinlock_t lock; 


#ifdef CONFIG_SMP 


const struct cpumask* affinity. hint; 


#endif 
atomic_t threads_active ; 
wait_queue_head_t wait, for threads; 


#ifdef CONFIG. PROC. FS 

struct proc, dir entry — * dir; 
#endif 

const char * name; 


| cacheline. internodealigned. in smp; 


每 个 irq_desc 是 对 中 断 号 的 抽象 描述 ; 而 iq chip Z&XJ HP THE mil ss AN A XR affinity 
则 是 对 中 断 处 理 在 哪些 处 理 咒 上 执行 的 抽象 描述 ; 还 有 对 中 断 信号 的 处 理 方式 则 是 通过 han- 
dle irq 来 进行 描述 ; 最 后 需要 抽象 出 来 的 就 是 不 同 设备 特别 地 处 理 了 ， 这 个 工作 就 由 action 
来 完成 。 其 他 的 都 是 表明 相关 操作 的 属性 以 及 和 中 断 在 哪个 执行 实体 上 运行 相关 。 通 过 这 些 
抽象 结构 就 可 以 实现 整个 中 断 处 理 的 框架 。 当 然 随 着 Linux 内 核 的 演进 ， 这 些 抽象 数据 结构 
的 具体 形式 会 有 变化 〈 如 结构 中 注释 所 说 ) ， 但 是 要 满足 中 断 处 理 的 需求 ， 框 架 中 必然 会 有 
物理 实体 的 抽象 ， 这 个 是 不 会 发 生变 化 的 。 明 白 了 这 些 抽象 结构 表示 的 物理 实体 ， 也 就 比较 
容易 理解 框架 的 执行 过 程 和 人 逻辑 了 ， 图 4-27 以 ARM 为 例 展示 了 中 断 处 理 代 码 的 流程 和 抽 
象 结 构 之 间 的 关系 。 

中 断 处 理 的 基本 操作 逻辑 就 是 先 获 得 正确 的 中 断 号 ， 然 后 由 相应 中 断 信号 处 理 方式 han- 
dle_irq 处 理 。 handle irq 会 根据 需要 ， 对 中 断 控制 器 进行 操作 ， 以 保证 中 断 控制 右 仍 然 能 够 
正确 地 上 报 中 断 ， 另 外 根据 action 中 的 操作 完成 设备 申请 的 操作 逻辑 。 

2. 中 断 处 理 延 时 操作 

下 面 介绍 系统 如 何 解决 中 断 中 大 数据 量 时 的 延 时 处 理 问题 。 图 4-28 是 Linux 内 核 中 断 
处 理 流程 。 
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HE >  irq usr—»irq handler asm do IRQ—»generic handle irq —generic handle ir desc —»(desc-^handle irq) —>handle_IRQ_event—>action->handler_do_IRQ 
. drq svc 


soe | matic | | aac | | tee | se 




















irqaction irqaction 









irqaction 


图 4-27 Linux 内 核 中 断 处 理 代码 流程 和 抽象 结构 的 关系 
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Al 4-28 Linux 内 核 中 断 处 理 流程 


从 图 4-28 中 可 见 ，Linux 内 核 中 断 处 理 分 为 两 部 分 ， 分 别 为 hardirq 和 softirg, hardirq 

部 分 决定 中 断 控 制 器 是 否 能 继续 上 报 中 断 的 时 间 ， 可 以 理解 为 硬件 的 中 断 延 时 时 间 ， 中 上 断 处 

理 系统 将 需要 进行 大 量 数据 处 理 的 工作 放 到 了 softirq 中 进行 。 这 样 将 完整 的 中 断 处 理 分 为 两 

部 分 进行 ， 既 保证 了 硬件 的 最 小 时 延 又 保证 了 数据 的 处 理 。softirq 是 Linux 内 核 采用 的 比较 

老 的 机 制 ， 是 对 中 断 数 据 处 理 的 一 种 延 时 操作 ， 也 可 将 其 作为 延 时 处 理 来 考虑 ， 相 应 的 介绍 

有 很 多 ， 这 里 就 不 进行 说 明了 。 中 断 的 数据 处 理 部 分 采用 内 核 线程 处 理 是 一 种 很 直接 的 方 
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式 ， 内 核 也 提供 了 该 方式 相应 接口 request_threaded_irq, iit ps 查看 任务 时 ， 若 见 到 如 下 信 
息 ([irq/ 中 断 号 -名 字 ] )， 就 说 明 是 中 断 处 理 线程 。 








root 549 0.0 0.0 0 0 7 S 07:20 0:00 [ irq/44 — mei] 


下 面 对 request, threaded, irq 接口 进行 一 下 介绍 : 
request. threaded, irq( unsigned int irq, irq_handler_t handler, irq_handler_t thread, fn, un- 
signed long flags, const char * name, void * dev) ; 
* irq 需要 申请 的 中 断 号 。 
* handler 一 一 中 断 处 理 逻 辑 接口 。 该 接口 运行 在 中 断 上 下 文中 ,只 是 执行 需要 快速 响应 
的 操作 ,执行 时 间 尽 可 能 短小 , 耗 时 的 工作 留 给 线程 处 理 接口 。 
© thread. fn 如 果 该 参数 不 为 NULL, 内 核 会 为 该 irq 创建 一 个 内 核 线程 。 当 中 断 发 生 
时 ， 如 果 handler 返回 值 是 IRQ_WAKE_THREAD ， 内 核 将 会 激活 中 断 线 程 ， 在 中 断 线 
程 中 ，thread_f 指向 的 接口 函数 将 被 调用 。 该 接口 函数 运行 在 进程 上 下 文中 ， 人 允许 进 
行 阻塞 操作 。 
控制 中 断 行 为 的 位 标志 ， 形 式 为 IJRQOF_XXXX， 例 如 : IRQF_TRIGGER_RIS- 
ING, IRQF TRIGGER. LOW, IRQF SHARED 等 。 




















® flags 





* name ms d P As MW PR, TIN EA rp BER REB BK 
* dev {EH handler 和 thread. fn 的 参数 ， 通 常设 置 为 设备 的 管理 实体 。 





3. 内 核 提供 的 通用 接口 

为 了 方便 开发 ， 内 核 为 访问 中 断 处 理 框 架 中 抽象 的 控制 结构 提供 了 一 些 接口 函数 . 

€ irq_set_chip(irq, * chip)/irq_get_chip(irq) 一 一 每 个 中 断 号 irq_chip 的 操作 接口 。 

e irq_set_handler_data( irq，* data)/irq_get_handler_data(irq) 一 一 每 个 中 断 号 内 中 断 处 
理 逻 辑 的 私有 数据 ,保存 handler 所 需要 的 特殊 数据 ， 例 如 中 断 控制 器 级 联 时 ， 进 行 
级 联 的 中 断 号 ， 用 该 字段 保存 下 一 级 中 断 号 的 管理 实体 。 

€ irqg_set_chip_data(irq, * data) /irq_get_chip_data (irq ) 一 一 每 个 中 断 号 内 操作 中 断 控 制 
器 的 私有 数据 ， 用 于 不 同 的 中 断 控制 器 管理 信息 。 

® irq set irq. type( irq, type) 用 于 设置 中 断 的 触发 类 型 ， 可 选 的 类 型 有 IRQ. TYPE 
EDGE RISING, IRQ. TYPE EDGE. FALLING, IRQ TYPE EDGE. BOTH, IRQ_TYPE_ 
LEVEL HIGH, IRQ TYPE LEVEL LOW, 

设置 中 断 处 理 逻 辑 ， 参 数 handle 的 类 型 是 irq_flow_ 

















€ irq set handler(irq, handle) 
handler. t 


[E] EB i E n DB Ab 85397 BLT fl 





e irq set chip and handler(irq, * chip, handle) 
器 属性 。 
e irq set chained handler(irq, * chip, handle) 








进行 级 联 的 中 断 号 ， 设 置 级 联 的 中 断 
处 理 逻 辑 ， 其 中 会 设置 标志 IRQ_NOREQUEST, IRQ. NOPROBE, IRQ_NOTHREAD, 
通常 用 于 中 断 控制 器 的 级 联 ， 设 置 上 述 三 个 标志 位 会 使 得 父 控制 器 的 相应 中 断 号 不 允 
许 被 驱动 程序 申请 。 

另外 内 核 还 提供 了 一 些 中 断 信 号 处 理 的 方式 : 


* handle_level_irq。 
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* handle_edge_irq. 

* handle_fasteoi_irq, 

* handle simple irq, 

* handle percpu  irq, 

* handle edge eoi irq, 

* handle bad irq, 

为 设备 开发 提供 的 中 断 请 求 的 接口 是 request. irq 和 request. threaded, irq. 

中 断 子 系统 还 提供 一 些 接口 用 于 动态 申请 /扩展 中 断 号 (需要 配置 CONFIG_SPARSE_ 
IRQ) ， 分 别 如 下 : 


irq_alloc_desc (node ) 














申请 一 个 irq, node 是 对 应 内 存 节点 的 编号 。 
在 指定 位 置 申请 一 个 iiq， 如 果 指 定位 置 已 经 被 占用 则 




















irq_alloc_desc_at ( at, node ) 
失败 。 


irq_alloc_desc_from( from, node) 





从 指定 位 置 开始 搜索 ， 申 请 一 个 irq。 
申请 多 个 连续 的 irq 编号 ， 从 from 位 置 开 始 搜索 。 
irq_free_descs( irq, ent) 释放 irq 资源 。 

这 些 只 是 申请 函数 ， 要 想 中 断 能 够 正常 工作 ， 还 需要 通过 接口 对 必要 的 字段 进行 设置 ， 
如 irq_set_chip_and_handler_name 、irq_set_handler_data 、irq_set_chip_data。 

中 断 处 理 系 统 还 提供 了 接口 ， 可 以 方便 其 他 模块 查询 当前 所 在 的 中 断 处 理 状态 ， 利 于 模 
块 做 出 正确 的 处 理 。 其 接口 如 下 : 

© in_irq( ) 一 一 判断 当前 是 否 在 硬件 中 断 上 下 文 。 

© in. softirq( ) 一 一 判断 当前 是 否 在 软件 中 断 上 下 文 。 

© in interrupt( ) 一 一 判断 当前 是 否 进行 中 断 处 理 ， 包 括 在 硬件 、 软 件 、 底 半 部 中 断 上 下 文 。 

这 些 接口 函数 是 实现 具体 处 理 器 及 设备 中 晰 处 理 的 基础 ， 为 各 种 驱动 和 处 理 器 提供 了 良 
好 的 操作 框架 。 

4. 电源 管理 相关 接口 

以 上 主要 是 中 断 处 理 框架 的 通用 功能 。 在 电源 管理 方面 ， 中 断 还 是 有 一 定 作 用 的 。 中 断 
可 以 作为 唤醒 系统 的 信号 ， 使 得 系统 在 进入 待机 时 能 够 被 唤醒 ， 而 这 需要 中 断 控制 器 的 支 
持 。 为 了 实现 该 功能 ， 系 统 在 中 断 控制 器 的 抽象 实体 irq_chip 中 进行 了 相关 的 设计 。 下 面 列 
出 了 irq_chip 中 的 主要 接口 : 





irq_alloc_descs ( irq ,from , ent , node ) 












































struct irq_chip | 


const char * name; 


unsigned int  ( ** irq. startup) (struct irq_data * data) ; 
void ( ** irq. shutdown) (struct irq_data * data) ; 
void ( ** irq-. enable) ( struct irq_data * data); 

void ( ** irq. disable) (struct irq_data * data); 


void ( * irq_ack) (struct irq-. data. * data) ; 
void ( * irq_mask ) (struct irq_data * data) ; 


void ( * irq_mask_ack) (struct irq_data * data) ; 
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void ( *irq unmask) (struct irq_data * data) ; 
int ( * irq_set_wake) (struct irq_data * data, unsigned int on) ; 
a 
其 中 ，irq_set_wake 是 和 唤醒 相关 的 功能 ， 主 要 是 打开 或 关闭 相应 中 断 唤醒 系统 的 功能 。 
内 核 提 供 对 某 个 中 断 进行 电源 管理 唤醒 功能 的 操作 接口 ， 接 口 为 int set_irq_wake( un- 


signed int irq, unsigned int on) ; 


可 见 内 核 中 断 处 理 框架 提供 了 包括 功能 、 性 能 和 电源 管理 相关 的 完整 系统 方案 。 
4.3.3 TI 芯片 中 断 处理 相 关 实 现 详 解 


首先 来 看 看 DM 3730 中 断 控 制 器 的 框架 ， 如 图 4-29 所 示 。 图 4-29 引 自 《DM 3730 ith 
片 手 册 》 中 第 2406 页 的 框图 。 
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图 4-29 DM 3730 中 断 控 制 器 框图 


从 图 4-29 可 见 ， 中 断 控制 器 的 时 钟 等 信号 是 在 PRCM 的 管理 之 下 ， 所 以 相应 的 也 有 电 
源 管理 的 功能 ， 后 续 的 代码 注释 中 对 相关 的 代码 进行 了 说 明 。 但 是 由 于 电源 管理 的 框架 还 没 
有 进行 介绍 ， 所 以 中 断 控制 器 中 相关 电源 管理 的 代码 可 以 先 浏览 ， 等 到 了 解 电源 管理 框架 之 
后 会 有 更 加 深入 的 理解 。 

接 下 来 分 步 说 明 中 断 处 理 的 具体 实现 。 

1. 中 断 号 实现 

从 图 4-29 中 可 见 ， 中 断 控 制 器 有 96 个 中 断 ， 这 些 中 断 号 是 如 何 定 义 的 ， 又 如 何 让 系统 
知道 正确 的 中 断 数 目的 呢 ? 

Linux 内 核 irqdesc. h 中 有 如 下 定义 : 
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extern struct irq_desc irq_desc[ NR_IRQS ] ; 





这 里 可 见 宏 NR_IRQS 描述 了 所 有 中 断 的 个 数 ， 这 个 数目 应 


应 该 是 和 处 理 器 相关 的 。DM 


3730 上 NR_IRQS 的 具体 值 以 及 中 断 号 的 定义 在 arch/arm/plat - omap/include/mach/irqs. h 中 


可 见 ， 具 体 如 下 : 


#define INT_34XX_BENCH_MPU_EMUL 3 
define INT 34XX ST MCBSP2 IRQ 4 
#define INT 34XX ST MCBSP3 IRQ 5 











#define INT_34XX_GPIO_BANK1 29 
#define INT_34XX_GPIO_BANK2 30 
#define INT_34XX_GPIO_BANK3 31 
#define INT_34XX_GPIO_BANK4 32 
#define INT_34XX_GPIO_BANKS 33 
#define INT_34XX_GPIO_BANK6 34 








#define INT_34XX_MMC3_IRQ 94 
#define INT_34XX_GPT12_IRQ 95 








#define NR_IRQS OMAP_GPMC_IRQ_END 


这 里 为 什么 不 是 96 的 数值 ， 而 是 另外 的 一 个 宏 呢 ? 其 实 这 是 为 了 解决 中 断 级 联 的 问题 。 
之 前 在 框架 设计 中 已 经 看 到 ， 通 过 irq_action 可 以 解决 中 断 共 享 ， 但 是 并 没有 说 明 如 何 解决 
中 断 级 联 。 其 实 中 断 级 联 就 是 通过 irq desc 自身 解决 的 ， 比 如 GPIO 做 中 断 源 的 话 就 会 产生 
级 联 中 断 的 情况 ， 这 样 中 断 号 就 需要 增加 ， 就 像 需 求 中 讨论 的 某 些 中 断 号 (如 INT_34XX_ 











GPIO BANKx) 会 作为 特殊 中 断 来 进行 处 理 ， 在 Linux 内 核 中 ， 











是 通过 set_irq_chained_han- 


dler 来 实现 该 功能 的 。 注 意 DM 3730 内 核 不 支持 配置 CONFIG_SPARSE_IRQ， 所 以 不 能 用 动 
态 申 请 的 方式 支持 级 联 ， 而 只 能 采用 静态 扩大 中 断 号 的 方式 。 具 体 的 级 联 中 断 的 解决 办 法 留 





到 相应 模块 中 进行 详细 说 明 。 
2. ARM 向 量 表 到 中 断 处 理 的 实现 





ARM 内 核 的 中 断 处 理 是 从 向 量 表 开始 的 。 向 量 表 在 arch/arm/kernel/entry, armv. S 中 


定义 : 


.globl ^ stubs start 


.. Stubs, start; 
vector stub irq, IRQ MODE, 4 


.long  irq_usr € 0 (USR 26/USR 32) 
.long ^  irq invalid @ 1 (FIQ 26/FIQ 32) 
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.long  ___ irq_invalid @ 2 (IRQ_26/IRQ_32) 
.long __ irq svc @ 3 (SVC26/SVC 32) 


vector stub dabt, ABT MODE, 8 


.long ^  dabt usr @ 0 (USR 26/USR 32) 

.long ^  dabt invalid € 1 (FIQ 26/FIQ 32) 

.long ^  dabt invalid @ 2 (IRQ 26/IRQ 32) 

.long ^  dabt sve @ 3 (SVC 26/SVC 32) 
vector fiq: 


disable. fiq 
subs pe, lr, #4 


.globl __ stubs_end 


. stubs end; 
. equ stubs offset, ^ vectors start +0x200 — — stubs start 
.globl ^ vectors start 


_ vectors start; 


ARM( swi SYS ERRORO  ) 


THUMB( sve #0 ) 
THUMB( nop ) 
W(b) vector und - stubs. offset 


W(ldr) pe, . LCvswi + stubs. offset 
W(b) vector pabt + stubs, offset 
W(b) vector dabt + stubs. offset 


W(b) vector addrexeptn + stubs, offset 





W(b) vector irq + stubs. offset 
W(b) vector. fiq stubs offset 


.globl ^ vectors end 


| vectors end: 


这 部 分 代码 主要 分 为 两 部 分 : 其 一 是 真正 的 [5] 量 表 ; 位 于 vectors, start 和 vectors 
end 之 间 ; 其 二 是 处 理 跳 转 的 部 分 ， 位 于 _ stubs start 和 stubs. end 之 间 。 








vector stub irq, IRQ MODE, 4 








这 名 其 实 是 宏 把 宏 展 开 后 就 定义 了 vector_irqg。 根 据 进入 中 断 前 的 处 理 器 模式 ， 分 别 跳 
转 到 irq_usr 或 O irq_sveo 
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vector_stub dabt, ABT_MODE, 8 


这 句 宏 展开 后 就 定义 了 vector_dabt, WHEA PARTAJAR EAREN, SPIKES dabt_ 
usr 2X, —dabt sve, 

在 系统 启动 阶段 ， 由 early trap init() (位 于 arch/arm/kernel/traps. c 中) 初始 化 向 量 表 
的 过 程 如 下 : 





void init early_trap_init( void) 


J * 
* Copy the vectors, stubs and kuser helpers( in entry — army. S) 
* into the vector page, mapped at Oxffff0000 , and ensure these 


* are visible to the instruction stream. 


*/ 
memepy( (void * )vectors, ^ vectors start, ^ vectors end — vectors start) ; 
memepy( (void * )vectors +0x200, —— stubs start, stubs end — stubs start) ; 





以 上 两 个 memepy ZH vectors. start 开始 的 代码 复制 到 0xffff0000 处 ， 把 _ stubs, start FF 
始 的 代码 复制 到 Oxffff0000 +0x200 处 ， 和 相对 跳 转 的 偏 移 相 同 。 这 样 异常 中 断 到 来 时 ，CPU 
就 可 以 正确 地 跳 转 到 相应 中 断 向 量 入 口 并 执行 了 。 

为 什么 要 将 stubs. start 开始 的 内 容 进行 如 此 的 复制 呢 ? 这 里 说 明 一 下 ， 先 看 看 内 核 编 
译 后 的 符号 表 : 





c000b4a0 T ^ stubs. start 
c000b4a0 t vector irq 
c000b520 t vector. dabt 
c000b5a0 t vector. pabt 
c000b620 t vector und 
c000b6a0 t vector. fiq 
c000b6a4 t vector addrexcptn 
c000b6c4 T ^ stubs end 
c000b6c4 T ^ vectors start 
c000b6e4 T ^ vectors end 


可 见 stubs start 在 向 量 表 内 容 之 前 ， 而 根据 向 量 处 理 的 映射 ， 整 个 向 量 处 理 的 代码 都 
需要 在 0xffff0000 之 后 的 一 个 页 内 ， 所 以 就 需要 将 stubs start 开始 的 内 容 进 行 复 制 ， 这 也 
是 需要 进行 偏 移 修 正 的 原因 。 

对 于 中 断 使 用 vector. stub 方式 如 下 : 
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vector_stub irq, IRQ MODE, 4 
进一步 分 析 vector. stub : 


.macro vector stub, name, mode, correction =0 
.align 5 
vector Mname: 
. if \correction 
sublr, lr, #\correction @ 异常 时 硬件 会 将 下 加 偏 移 , 要 修正 才能 得 到 正确 的 返回 值 
. endif 





@ Save 10, lr. « exception > (parent PC) and spsr_ < exception > 
@ (parent CPSR) 


stmia sp, |10, lr} @ save 10, lr 
mrs lr, spsr € Ir (RFF spsr 的 值 为 后 续 使 用 ,spsr 为 进入 向 量 之 前 的 状态 
str lr, [sp, 48] @ save spsr 


@ Prepare for SVC32 mode. IRQs remain disabled. 

mrsr0, cpsr 

eoriÜ , 10, #( \mode ^ SVC_MODE | PSR, ISETSTATE) 

msrspsr_cxsf, 10 ”@ 把 10 的 值 写 入 spsr 寄存 器 (cxsf 表示 要 写 哪些 位 ) 
@ 此 时 spsr 的 值 已 经 包含 了 SVC_MODE 

@ the branch table must immediately follow this code 

andlr, lr, #0x0f @ lr 为 保存 的 spsr 的 值 ,此 语句 取 到 进入 异常 前 的 模式 





THUMB( adm, 1f ) 
THUMB( ldrlr, [ 10, Ir, Isl 42] ) 
movr0, sp 
ARM( ldrlr, [ pc, lr, Isl #2] ) @lr=pc+modex4 根 据 模式 获得 正确 的 指令 地 址 
@ 根 据 thumb 指令 可 知 pe 指针 值 为 1 标号 处 ， 
@ pe 为 此 值 和 指令 流水 有 关 
movs pc, lr @ branch to handler in SVC mode 


@ 这 里 会 将 spsr A cpsr 保证 是 在 SVC 模式 执行 处 理 
ENDPROC( vector_\name) 


. align 2 


(9 handler addresses follow this label 


. endm 


中 断 处 理 上 述 代码 ， 最 终 会 根据 之 前 的 模式 进入 irq_ust 或 者 irq_sve 执行 ， 二 者 最 
终 都 会 进入 irq_handler 这 个 宏 : 
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. macro irq_handler 
get irqnr. preamble r5 , Ir 
1: get irqnr and, base 10, 16, r5, lr 
movne rl, sp 
@ 
@ routine called with 10 = irq number, rl = struct pt regs * 
@ 
adrne Ir, BSYM(1b) 
bneasm_do_IRQ 


get_irqnr_preamble 和 get_irqnr_and_base 这 两 个 宏 由 板 级 支持 的 代码 在 arch/arm/ plat — 
omap/include/mach/entry - macro. S 中 定义 ,目的 就 是 从 中 断 控制 右 中 获得 正确 的 中 断 号 , 来 
看 看 相应 的 实现 : 


#if defined( CONFIG_ARCH_OMAP2) || defined( CONFIG_ARCH_OMAP3) 
. macro get_irqnr_preamble, base, tmp 

#ifdef CONFIG_ARCH_OMAP2 
ldr \base, =OMAP2_IRQ_BASE 

#else 
ldr \base, =OMAP3_IRQ_BASE 

#endif 


. endm 


/ * Check the pending interrupts. Note that base already set */ 
. macro get irqnr and base, irqnr, irgstat, base, tmp 
ldr \irgnr, [ \base, 40x98] / * IRQ pending reg 1 */ 
emp Virqnr, #0x0 
bne9999f 
Idr\irqnr, [ \base, #0xb8 | / * IRQ pending reg 2 */ 
emp \irqnr, #0x0 
bne9999f 
Idr\irqnr, [ \base, #0xd8 | / * IRQ pending reg 3 */ 
emp \irqnr, #0x0 
9999 . 
ldme \irgnr, | \base, &INTCPS SIR, IRQ. OFFSET] 
andVirqnr, Virqnr, #ACTIVEIRQ_ MASK / * Clear spurious bits * / 
. endm 


#endif 


/ * 
* Optimized irq functions for ti81xx 


mf 
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#ifdef CONFIG_ARCH_TI81 XX 
. macro get_irqnr_preamble, base, tmp 
Idr\base, = OMAP3 IRQ BASE 
. endm 
/ * Check the pending interrupts. Note that base already set * / 
. macroget irqnr and base, irqnr, irgstat, base, tmp 
Idr\irqnr, [ \base, 40x98] / * IRQ pending reg 1 */ 
emp \irqnr, #0x0 
bne9999f 
Idr\irqnr, [ \base, #0xb8] / * IRQ pending reg 2 */ 
cmp \irqnr, #0x0 
bne9999f 
Idr\irqnr, [ \base, 40xd8] / * IRQ pending reg 3 */ 
emp \irqnr, #0x0 
bne9999f 
Idr\irqnr, [ \base, 40xf8] / * IRQ pending reg 4 */ 
emp \irqnr, #0x0 

9999 . 
ldme — Virqnr, | \base, &£INTCPS SIR, IRQ. OFFSET ] 
and Virqnr, Virqnr, #ACTIVEIRQ_MASK 
. endm 


#endif 


#ifdef CONFIG_ARCH_OMAP4 

. macro get_irqnr_preamble, base, tmp 

ldr \base, =OMAP4_IRQ_BASE 

. endm 

Ie 
* The interrupt numbering scheme is defined in the 
* interrupt controller spec. To wit: 
* 
* Interrupts 0 — 15 are IPI 
* 16-28 are reserved 
* 29-31 are local. We allow 30 to be used for the watchdog. 
* 32 — 1020 are global 
* 1021 — 1022 are reserved 


* 1023 is "spurious" (no interrupt) 


* For now, we ignore all local interrupts so only return an 
* interrupt if it s between 30 and 1020. The test, for ipi 


* routine below will pick up on IPIs. 
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* 


A simple read from the controller will tell us the number 
* of the highest priority enabled interrupt. 
* We then just need to check whether it is in the 
* valid range for an IRQ(30 - 1020 inclusive). 
*/ 
. macro get irqnr and base, irqnr, irqstat, base, tmp 
ldr \irgstat, [ \base, #GIC_CPU_INTACK | 
ldr \tmp, = 1021 
bic \irqnr, Virqstat, #0x1c00 
emp Virqnr, #29 
empec \irqnr, \irqnr 
cmpne \irgnr, Mmp 
cmpcs \irgnr, Virqnr 
. endm 


#endif 


从 这 可 见 ， 无 论 DM 3730, TI816X 还 是 OMAP4 都 有 自己 的 实现 ， 其 中 比较 重要 的 是 宏 
OMAPx IRQ BASE, ， 这 是 中 断 控制 器 的 基地 址 ，get_irqnr_preamble 就 是 通过 该 宏 获 得 中 断 
控制 如 的 基地 址 的 。 而 get_irqnr_and_base 也 需要 该 基地 址 来 获得 正确 的 触发 中 断 的 中 断 号 。 
在 irq_handler 获得 正确 的 中 断 号 之 后 ， 紧 接着 就 调用 asm_do_IRQ， 从 这 个 函数 开始 ， 中 断 
程序 进入 C 代码 中 。 该 函数 在 arch/arm/kernel/irg. c 中， 实现 如 下 . 











asmlinkage void ^ exception asm_do_IRQ( unsigned int irq, struct pt_regs * regs) 
| 


struct pt_regs * old_regs = set_irq_regs( regs) ; 


irq_enter( ) ; 


P 
* Some hardware gives randomly wrong interrupts. Rather 
* than crashing, do something sensible. 

*/ 
if( unlikely( irq >= nr. irqs) ) | 
if( printk_ratelimit( ) ) 
printk( KERN. WARNING "Bad IRQ96u Wn" , irq); 
ack, bad. irq( irq) ; 
\ else | 


generic handle irq( irq) ; 


/** ATOI specific workaround * / 
irq_finish( irq) ; 

irq. exit( ) ; 

set, irq. regs( old. regs) ; 
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到 这 里 ， 中 断 处 理 就 完成 了 从 向 量 表 到 体系 结构 无 关 的 generic_handle_irg 中 断 处 理 的 
转换 ， 后续 可 以 根据 正确 的 中 断 号 进行 中 断 处 理 了 。 

3. 中 断 控制 器 的 处 理 

接 下 来 看 看 DM 3730 的 内 核 是 如 何 实现 中 断 控制 器 的 管理 的 。 首 先 ， 看 一 下 DM 3730 
中 断 控制 器 的 内 部 框架 ， 如 图 4-30 所 示 。 图 4-30 引 自 《DM 3730 芯片 手册 》 中 第 2411 页 
的 框图 。 
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从 图 4-30 中 可 见 ， 该 中 断 控 制 器 可 进行 中 断 的 优先 级 管理 ， 并 能 屏蔽 中 断 ， 以 及 伪 中 
断 的 检查 ， 这 些 都 是 内 核 需 要 的 中 断 控制 带 的 功能 。DM 3730 中 断 控 制 器 的 实现 代码 在 
linux/arch/arm/mach - omap2/irq. c 中 。 中 断 控制 器 的 管理 主要 是 实现 irq_chip 的 操作 接口 ， 
该 接口 提供 给 内 核 的 中 断 处 理 框 架 ， 通 过 这 些 接口 ， 内 核 可 在 其 提供 的 标准 中 断 处 理 流 程 接 
口 irq_flow_handler_t 中 调用 如 ack, mask, unmask 等 操作 ， 从 而 正确 完成 整个 的 中 断 处 理 流 
程 。 现 将 中 断 控 制 右 管理 相关 的 代码 整理 到 一 起 ， 并 注释 如 下 . 























/* selected INTC register offsets */ 


/中断 控制 需 寄 存 器 偏 移 地 址 











#define INTC_REVISION 0x0000 
#define INTC_SYSCONFIG 0x0010 
#define INTC. SYSSTATUS 0x0014 
#define INTC. SIR 0x0040 

#define INTC. CONTROL 0x0048 
#define INTC. PROTECTION 0x004C 
#define INTC_IDLEO x0050 

#define INTC_THRESHOLDO x0068 
#define INTC_MIROO x0084 

#define INTC MIR. CLEAROO x0088 
#define INTC. MIR. SETOO x008c 
#define INTC_PENDING_IRQOO x0098 





/ * Number of IRQ state bits in each MIR register * / 
#define IRQ_BITS_PER_REG 32 





// 该 结构 是 针对 如 果 omap 中 包含 多 个 inte 控制 bank , 则 每 个 bank 有 自己 的 相应 管理 实体 。 为 扩 
// 展 留 有 余地 
static struct omap_irq_bank | 
void _ iomem * base reg; 
unsigned int nr irqs; 
| _ attribute _ ((aligned(4) ) )irq banks[ | = | 
| 
/* MPU INTC */ 
.nr irqs =96, 
E 
E 
// PEE til a ATAR ET FB O PRU, FP Ey ED Hk, XF DM 3730 相关 的 管理 实体 就 是 
//irq. banks[ 0 | 
static void inte, bank, write reg( u32 val, struct omap_irq_bank * bank, ul6 reg) 


| 





. raw, writel( val, bank -> base reg + reg) ; 
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static u32 intc_bank_read_reg( struct omap_irq_bank * bank, ul6 reg) 


return raw, readl( bank — > base_reg + reg) ; 


static int previous_irq; 


* On 34xx we can get occasional spurious interrupts if the ack from 

* an interrupt handler does not get posted before we unmask. Warn about 

* the interrupt handlers that need to flush posted writes. 

*/ 
// 检 查 伪 中 断 。 由 于 DM 3730 的 中 断 控制 器 是 电 平 触发 的 ,如 果 中 断 处 理 程序 处 理 不 当 , 很 可 能 
// 会 有 中 断 误 报 的 伪 中 断 现 象 ,这 里 可 进行 检查 并 报错 。 使 用 该 函数 主要 是 为 了 发 现 中 断 处 理 函 
// 数 的 问题 
// 例 如 出 现 warning Spurious irq 95; Oxffffffdf, please flush posted write for irq 86 























// 通 常设 备 的 中 断 处 理 函 数 中 ,需要 写 相应 的 寄存 器 ,表明 中 断 处 理 了 ,这样 相 应 的 设备 模块 可 以 
/停止 给 中 断 控 制 需 发 送 中 断 请 求 。 由 于 对 于 寄存 需 的 写 操作 是 异步 ,如 果 相 应 的 寄存 顺 还 没有 
// 生 效 ,而 由 于 内 核 的 中 断 处 理 函 数 在 调用 irq_handler 之 后 会 调用 中 断 控制 絮 的 umask ,此 时 如 
// 果 正 有 中 断 报 给 中 断 控 制 咒 ,在 硬件 上 就 会 造成 伪 中 断 spurious 的 问题 
// 这 时 需要 将 相应 中 断 号 的 设备 中 断 处 理 函 数 的 寄存 需 读 一 下 以 保证 写 完 


























//{DM 3730 芯片 手册 》 中 具体 的 spurious 说 明 (在 2421 页 ) 如 下 

// The spurious flag indicates whether the result of the sorting( a window of 10 INTC 

// functional clock cycles after the interrupt assertion) is invalid. The sorting is invalid if; 
// The interrupt that triggered the sorting is no longer active during the sorting. 

// A change in the mask has affected the result during the sorting time. 

static int omap. check spurious( unsigned int irq) 

| 


u32 sir, spurious; 


/就 是 通过 读 INTC_SIR 的 高 位 ,其 中 包含 伪 中 断 标识 符 
sir = inte, bank, read, reg( &irq_banks[ 0] , INTC_SIR) ; 





spurious = sir > 7; 


if( spurious ) | 
printk( KERN. WARNING "Spurious irq 96i; 0x%08x, please flush " 
"posted write for irq 96iWn" , 
irq, sir, previous irq) ; 


return spurious; 
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return 0; 


/* XXX; FIQ and additional INTC support( only MPU at the moment) * / 
//DM 3730 的 irq ack 函数 主要 是 为 中 断 控制 器 的 ack 函数 接口 
static void omap_ack_irq( unsigned int irq) 


| 








// 操 作 INTCPS_CONTROL 寄存 器 , 往 该 寄存 器 的 NEWIRQAGR 位 写 1 
/人 /表明 重 置 中 断 输出 ,使 能 新 的 中 断 源 
inte, bank, write reg( 0x1, &irq_banks[ 0], INTC_CONTROL) ; 




















// 屏 项 指定 的 irq, TE TA EROR EE RT BET E spurious 中 断 的 记录 . 
static void omap. mask irq( unsigned int irq) 


| 





// 该 offset 为 相应 的 MIR_SETn 寄存 器 的 mn 值 ,表示 第 n 个 寄存 器 
// 根 据 ing 号 进行 下 面 计算 即 可 
int offset = irq &( ~ (IRQ. BITS. PER. REG -1)); 





if( cpu_is_omap34xx() ) | 


int spurious 20; 


JEF 
* INT_34XX_GPT12_IRQ is also the spurious irq. Maybe because 


* it is the highest irq number? 
































*/ 
// 这 里 通过 定时 中 断 来 定期 检查 是 否 有 spurious 伪 中 断 产 生 ， 
// 如 果 有 则 显示 信息 








if( irq == INT_34XX_GPT12_IRQ) 


spurious = omap_check_spurious( irq) ; 








// 这 里 记录 相应 的 中 断 previous irq 是 为 了 记录 可 能 的 spurious 伪 中 断 。 由 于 这 里 是 
//mask irq ,而 之 前 分 析 了 可 能 产生 spurious 伪 中 断 是 之 前 的 umask irq ,所 以 这 里 记 
// 录 相应 的 irq 号 到 previous. irq 

// 而 下 一 次 如 果 omap_check_spurious 中 返回 非 0, 表 明 有 spurious 则 说 明 此 次 记录 到 
//previous_irq 的 irq 就 是 相应 的 spurious irq 








if( ! spurious) 


previous, irq = irq; 


// 有 了 相应 的 offset ,那么 寄存 器 中 应 该 写 入 低 32bits 的 值 
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// 通 过 与 操作 只 保留 低 32bits 值 
irq & = (IRQ_BITS_PER_REG - 1) ; 




















// 通 过 inte 接口 写 人 相应 的 寄存 器 ,omap3 只 有 bankO 
intc_bank_write_reg(1 << irq, &irq. banks| 0] , INTC_MIR_SETO + offset) ; 




















/ /irq 的 umask 操作 ,通过 写 MIR, CLEAR 寄存 器 实现 
static void omap_unmask_irq( unsigned int irq) 


| 
// 计 算 offset, E] mask 操作 
int offset =irq &( ~ (IRQ_BITS_PER_REG -1)); 


// 保 留 低 32bits 并 写 寄 存 器 
irq & = (IRQ_BITS_PER_REG -1); 


inte, bank, write reg(1 <<irq, &irq_banks[ 0] , INTC_MIR_CLEARO + offset) ; 





// 该 函数 作为 irq ack 的 接口 函数 ,ARM 核 本 身 有 MPU_INTC_FIQ #1 MPU. INTC. IRQ 两 个 
// 中 断 请 求 信 号 
static void omap_mask_ack_irq( unsigned int irq) 


| 

















// 首 先 要 mask 相应 的 id, 避免 外 部 模块 的 irq 重复 报告 给 ARM 
// 由 于 这 里 是 在 ARM cortex A8 core 之 外 的 inte ,需要 先 mask irq 


omap. mask. irq( irq) ; 











// YR ack 实现 写 inteps. control 寄存 器 来 重新 使 能 inte. irq 
omap_ack_irq( irq) ; 











// 这 里 是 ARM irq WEZ HY P EPE AEO irq_chip 
static struct irq_chip omap_irq_chip = | 

. name = " INTC" , 

. ack = omap. mask, ack irq, 

. mask = omap. mask. irq, 


. unmask = omap. unmask irq, 


bs 


4， 中 断 控制 器 初始 化 
中 断 控制 器 初始 化 相关 的 代码 和 具体 实现 说 明 如 下 : 


// 对 相应 bank 的 inte 进行 初始 化 ,主要 是 soft reset 并 设置 内 部 时 钟 为 autoidle( 节能 ) 
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static void __ init omap. irq. bank, init, one( struct omap_irq_bank * bank) 


unsigned long tmp; 


// 打 印 inte 的 版 本 信息 
tmp = intc_bank_read_reg(bank，INTC_REVISION ) & Oxff; 
printk( KERN. INFO "IRQ: Found an INTC at 0x% p " 
"(revision % ld. % ld) with 96d interrupts An" , 
bank -> base reg, tmp >>4, tmp & Oxf, bank -> nr irqs) ; 


// 通 过 sysconfig 寄存 器 reset 中 断 控制 器 

tmp = intc_bank_read_reg( bank, INTC_SYSCONFIG ) ; 
tmp |=1 <<1;/ * soft reset * / 

inte, bank, write reg( tmp, bank, INTC_SYSCONFIG) ; 





// 通 过 读 取 sysstatus 寄存 器 确认 reset 成 功 结束 
while(! (inte bank, read. reg( bank, INTC_SYSSTATUS) & 0x1) ) 


/ * Wait for reset to complete * /; 


//enable 内 部 clock 的 auto idle 模式 
/ * Enable autoidle * / 
inte, bank, write reg( 1 ««0, bank, INTC_SYSCONFIG) ; 





/内 核 中 板 级 的 中 断 初始 化 接口 。 在 machine, desc 中 的 init irg 会 调用 该 接口 , 该 函数 记录 相应 
// 的 中 断 控制 右 的 地 址 并 作 ioremap 供 内 核 使 用 ,还 对 中 断 控制 器 进行 初始 化 等 操作 ,最 后 最 重要 
// 的 是 要 对 内 核 的 中 断 描述 符 inq; desc 进行 必要 的 初始 化 

void ^ init omap_init_irq( void) 


| 








pa 





unsigned long nr of irqs 20; 
unsigned int nr banks 20; 


int 1; 








// 对 于 每 个 硬件 的 inte 模块 都 要 初始 化 
// 在 DM 3730 中 只 有 一 个 inte 供 ARM 使 用 ,所 以 实际 只 初始 化 一 次 
for(120; i < ARRAY SIZE(irq banks) ; i++ ) | 























unsigned long base =0; 


struct omap. irq. bank * bank = irq. banks + i; 


// 先 记录 实际 的 inte 寄存 器 的 物理 基地 址 
if( cpu_is_omap24xx( ) ) 
base = OMAP24XX IC, BASE; 
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else if( cpu, is omap34xx( ) ) 
base = OMAP34XX IC. BASE; 

else if( cpu, is ti81xx( ) ) | 
base = TIBIXX. ARM, INTC BASE; 
bank -> nr. irqs = 128; 





i 


// 基 地 址 为 0, 说 明 有 bug, 要 报告 
BUG. ON( !base) ; 


/ * Static mapping, never released * / 


// WS ep rm hl tt HE 
bank -> base, reg = ioremap( base, SZ_4K) ; 





if( !bank -> base. reg) | 
printk( KERN, ERR "Could not ioremap irq bank% iW" , i); 


continue ; 


// X] imc 进行 初始 化 ,包括 控制 器 的 soft reset 等 操作 


omap_irq_bank_init_one( bank) ; 








人 记录 到 目前 位 置 初始 化 后 有 多 少 中 断 可 以 激活 


nr of irqs += bank -> nr_irqs; 





nr_banks ++ ; 


printk( KERN, INFO " Total of % ld interrupts on 96 d active controller% s\n" 


nr of irqs, nr banks, nr banks >1 ? "s" ; ""); 


UE 


上 





/对 内 核 的 中 断 描 述 符 进 行 初始 化 ,要 正确 的 设置 中 断 控制 顺 
// 需 属性 。0 — nr of irqs 为 中 断 控 制 管理 的 中 断 号 
for(i =0; i <nr_of_irqs; i++) | 
/人 /设置 中 断 控 制 器 的 描述 符 , EE hl at I ED H 
set_irq_chip(i, &omap_irq_chip) ; 
































u 


//TRM 中 描述 了 inte 只 支持 level 触发 的 中 断 , 这 里 设置 相应 的 管理 











//handle 为 kernel 标准 的 level 触发 中 断 处 理 函 数 
set_irq_handler(i, handle level irq) ; 

// V E valid 标识 ,实际 表明 该 中 断 号 可 以 request 了 . 
set_irq_flags(i, IRQF_VALID) ; 





, 


EAS) irq- desc 的 中 断 控 币 


中 断 
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5. 电源 管理 相关 
最 后 来 看 看 电源 管理 相关 的 代码 ， 先 对 模块 的 电源 管理 有 个 初步 的 了 解 。 








/ * Structure to save interrupt controller context * / 
// 该 结构 是 针对 power 相关 的 save 和 restore 在 memory 中 保存 的 寄存 器 实体 ， 
// 以 便 wakeup reset 的 时 候 可 以 恢复 
struct omap3_intc_regs | 

u32 sysconfig ; 

u32 protection; 

u32 idle; 

u32 threshold; 

u32 ilr[ INTCPS_NR_IRQS] ; 

u32 mir[ INTCPS_NR_MIR_REGS] ; 
ss 


// 该 函数 是 留 给 power management 的 接口 ,在 进入 sleep 之 前 进行 最 后 的 检查 ,看 是 否 有 pending 
// 的 中 断 需 要 处 理 。 进 入睡 眼 的 操作 过 程 中 是 不 能 发 生 中 断 从 而 引起 上 下 文 切换 的 ,所 以 在 准备 
// 进 入 sleep 的 最 后 阶段 首先 要 disable 中 断 ,而 在 跳 到 sram 的 sleep 执行 之 前 需要 检查 是 否 有 
//pending 的 中 断 ,如 果 有 则 应 该 直接 恢复 并 enable 中 断 以 执行 中 断 处 理 。 这 里 就 是 进行 中 断 
//pending 的 检查 

// 通 常 该 函数 会 在 cpu idle 的 接口 中 被 调用 

int omap_irq_pending( void) 


| 






































int 1; 


for(i =0; i < ARRAY SIZE(irq banks) ; i++ ) | 
struct omap. irq. bank * bank = irq-. banks + i; 


int irq; 


for( irq 20; irq < bank -> nr_irqs; irq +=32) 
if( inte bank, read, reg( bank, INTC_PENDING_IRQO + 
((irq»55) ««5))) 
return 1; 


| 


return 0; 


#ifdef CONFIG_ARCH_OMAP3 
// 这 部 分 是 DM 3730 所 需要 的 . 
// 该 inte, context 为 power 相关 的 .需要 做 寄存 器 保护 的 上 下 文 . 


static struct omap3_intc_regs intc_context] ARRAY. SIZE( irq. banks) ] ; 


// 保 存 相 应 的 inte 的 上 下 文 ,作为 core_save_context 的 一 部 分 . 
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void omap. inte, save context( void ) 
| 
int ind =0, i=0; 
for( ind 20; ind < ARRAY_SIZE(irq_banks); ind ++ )| 
struct omap_irq_bank * bank = irq_banks + ind; 
inte_context[ ind ]. sysconfig = 
inte_bank_read_reg( bank, INTC_SYSCONFIG) ; 
inte, context[ ind ]. protection = 
inte_bank_read_reg( bank, INTC PROTECTION) ; 
inte, context[ ind |. idle = 
inte. bank, read. reg( bank, INTC IDLE) ; 
inte, context[ ind ]. threshold = 
inte. bank, read. reg( bank, INTC THRESHOLD) ; 
for(i=0; i < INTCPS_NR_IRQS; i++) 
inte, context[ ind ]. ilr[ i] = 
inte, bank, read. reg( bank , (0x100 +0x4 ** i) ) ; 
for(i=0; i < INTCPS. NR. MIR. REGS; i++) 
inte, context[ ind]. mir[ i] = 
inte, bank, read. reg( &irq_banks[ 0] , INTC. MIRO + 
(0x20 * i)); 

















//inte 的 上 下 文 恢 复 同样 作为 core_restore_context 的 一 部 分 
void omap_intc_restore_context( void ) 


| 





int ind =0, i=0; 


for( ind 20; ind < ARRAY_SIZE(irq_banks); ind ++ ) | 


struct omap. irq. bank. * bank = irq_banks + ind; 


=. 


inte, bank, write, reg( inte, context[ ind ]. sysconfig, 
bank, INTC_SYSCONFIG) ; 


inte, bank, write, reg( inte, context[ ind ]. sysconfig, 


bank, INTC_SYSCONFIG) ; 








inte. bank, write, reg( intc, context | ind ]. protection, 
bank, INTC PROTECTION) ; 

inte, bank, write, reg( inte, context[ ind ]. idle, 
bank, INTC_IDLE) ; 

inte, bank, write reg( inte, context[ ind |. threshold, 
bank, INTC_THRESHOLD) ; 

for(i=0; i<INTCPS_NR_IRQS; i++) 


inte, bank, write reg( inte, context| ind]. ilr[ i] , 
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bank , (0x100 +0x4 * i) ) ; 
for(i =0; i «INTCPS NR. MIR. REGS; i ++ ) 





inte, bank, write, reg( inte, context| ind]. mir[ i], 
&irq-. banks[ 0] , INTC. MIRO + (0x20 * i)) ; 
} 


/ * MIRs are saved and restore with other PRCM registers * / 


/7 清除 pending HY irq, 这 样 可 以 使 系统 进入 sleep 模式 。 在 系统 suspend 需要 强制 进入 sleep 时 使 用 
void omap3_intc_suspend( void ) 
| 
/* A pending interrupt would prevent OMAP from entering suspend */ 
// 由 于 pending 的 中 断 会 阻止 系统 进入 suspend 模式 ,通过 ack 操作 可 以 将 pending 的 中 断 
// 清 除 ,接收 新 的 中 断 从 而 保证 系统 可 以 进入 suspend 模式 . 
omap_ack_irq(0) ; 
































// 进 入 idle 的 准备 操作 ,该 操作 在 sram_idle 中 被 调用 . 
void omap3, inte, prepare, idle( void) 
| 
/* 
* Disable autoidle as it can stall interrupt controller, 
* cf errata ID i540 for 3430(all revisions up to 3. 1. x) 
*/ 
// 该 操作 为 勘误 中 的 说 明 , 由 于 内 部 ocp clock 在 auto idle 情况 下 会 自动 gating ,而 此 情况 下 系 
// 统 唤醒 时 ,由 于 inte 没有 内 部 的 clock 会 导致 无 法 产生 对 ARM 的 中 断 ,从 而 无 法 唤醒 整个 系统 
//workaround 就 是 在 sleep 之 前 将 inte 的 autoidle 关 掉 , 保 证 系统 唤醒 
// 时 inte 的 内 部 clock AZ gating 
inte, bank, write reg(0, &irq_banks[ 0] , INTC_SYSCONFIG) ; 




















/ / inte 唤醒 后 的 恢复 操作 . 
void omap3_intc_resume_idle( void) 


| 


/* Re- enable autoidle */ 
// 为 了 省 电 , 重 新 enable inte 的 autoidle ,从 而 可 以 内 部 clock auto gating. 
inte, bank, write reg( 1, &irq banks| 0] , INTC_SYSCONFIG) ; 





| 
#endif/ * CONFIG ARCH_OMAP3 */ 


电源 管理 没有 中 断 控 制 器 唤醒 的 相关 实现 ， 由 于 这 部 分 是 在 ARM 主 处 理 絮 的 电源 域 
中 ， 并 不 需要 这 部 分 功能 。 会 由 其 他 的 部 分 来 唤醒 系统 。 
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44 内 存 管理 


4.4.1 内 存 管理 的 基本 需求 


内 存 管理 是 Linux 内 核 非常 重要 的 功能 ， 可 以 说 是 最 基础 的 功能 之 一 。 在 介绍 最 小 系统 
的 时 候 ， 就 已 经 看 到 内 存 是 硬件 必 不 可 少 的 部 分 。 如 何 管理 内 存 一 直 是 一 个 综合 的 问题 ， 对 
于 内 存 的 管理 是 多 方面 的 ， 因 为 存储 系统 本 刁 就 是 一 个 有 层次 概念 的 系统 。 存 储 系统 的 层次 
结构 如 图 4-31 所 示 。 而 内 存 RAM 是 既 可 以 用 来 执行 指令 又 可 以 用 来 存放 数据 的 多 功能 存 
储 器 件 ， 而 且 在 存储 系统 层次 中 位 于 中 间 的 位 置 ， 起 到 承上启下 的 作用 ， 性价比 (速度 快 
并 且 价 格 低 ) 十 分 高 ， 这 样 就 附加 了 内 存 缓存 的 功能 需求 ， 用 于 缓存 底层 存储 系统 的 数据 。 
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图 4-31 存储 系统 层次 结构 


整个 内 存 管 理 的 首要 需求 自然 是 内 存 物 理 空间 的 管理 。 当 然 空间 的 管理 要 有 单元 的 概 
念 ， 并 且 单 元 大 小 要 合适 ， 单 元 小 则 需要 的 管理 资源 多 ， 单 元 大 就 会 有 浪费 。 由 于 处 理 器 是 
使 用 自己 的 视角 【地址 空间 ) 访问 内 存 ， 内 存 的 管理 也 要 从 处 理 右 的 角度 出 发 。 由 于 处 理 
器 使 用 虚拟 地 址 并 通过 映射 来 访问 内 存 ， 这 样 内 存 管理 就 不 能 只 关心 内 存 的 物理 空间 ， 还 要 
关心 虚拟 地 址 空间 ， 并 对 虚拟 地 址 空间 和 映射 关系 进行 管理 。 这 样 内 核 中 实际 的 内 存 管理 需 
求 就 包括 了 内 存 物理 空间 管理 、 虚 拟 地 址 空间 管理 ， 以 及 虚拟 地 址 和 内 存 物 理 地 址 映射 关系 
的 管理 。 

同样 内 存 管理 部 分 会 有 相应 的 性 能 需求 ， 主 要 是 减少 碎片 ， 包 括 外 部 碎片 和 内 部 碎片 
(与 管理 粒度 相关 ) 。 另 外 对 于 分 配 和 释放 也 有 性 能 的 要 求 〈 当然 是 越 快 越 好 ) 。 

作为 内 核 的 基础 功能 之 一 ， 内 存 管 理由 于 空间 的 限制 ， 需 要 将 各 种 模块 及 不 同情 况 下 对 
于 内 存 的 请 求 分 为 不 同 的 优先 级 和 不 同 的 方式 进行 操作 ， 这 些 也 是 内 存 管理 需要 满足 的 
需求 。 

随 着 SoC 芯片 技术 的 发 展 ， 愈 来 愈 多 的 协 处 理 器 加 入 到 了 SoC 中 。 特 别 是 视频 应 用 需求 
的 不 断 增 长 使 得 内 存 管理 的 需求 也 发 生 了 变化 ， 由 于 图 像 分 辨 率 以 及 显示 分 辨 率 的 不 断 提 
高 ， 而 协 处 理 器 通常 又 需要 连续 的 物理 内 存 ， 这 样 就 有 对 于 几 兆 甚至 十 几 兆 连续 内 存 管 理 的 
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需求 。 而 原 有 的 Linux 内 核 内 存 管 理 并 不 能 满足 这 种 需求 ， 这 样 就 需要 开发 新 的 内 存 管 理 方 
法 。 简 便 有 效 的 方法 是 将 相应 的 物理 空间 和 Linux. 内 核 的 空间 保持 分 离 ， 相 应 的 物理 空间 单 
独 进行 管理 ， 应 用 则 通过 映射 来 进行 访问 。 这 部 分 空间 通常 由 芯片 广 商 提 供 管理 方法 ， 如 
TI 的 CMEM, 、 高 通 的 PMEM 等 。 当 然 随 着 内 核 的 发 展 ， 芯 片 厂商 各 自 为 政 的 局 面 必然 得 到 
改观 。 现 今 内 核 也 在 逐渐 整合 这 部 分 功能 ， 提 出 了 一 些 独立 的 方案 ， 如 CMA 和 ION。 最 新 
的 内 核 有 对 两 者 进行 整合 的 趋势 ， 很 可 能 将 CMA 作为 ION 的 基础 。 不 管 怎样 ， 这 个 功能 需 
求 是 固定 的 ， 原 理 也 是 基本 一 致 的 ， 后 面 会 以 开 的 CMEM 为 例 进行 介绍 ， 至 于 内 核 最 终 的 
解决 形式 还 要 时 间 的 验证 。 


4.4.2 内 存 管理 框架 介绍 


Linux 内 核 中 的 内 存 管理 框架 考虑 到 了 各 个 方面 的 需求 ， 实 现 得 非常 精细 。 在 第 4. 2 节 
中 介绍 了 虚拟 空间 管理 中 内 核 地 址 映射 的 功能 ， 只 是 内 核 空 间 的 地 址 映射 太 重要 而 且 太 特殊 
了 ， 所 以 单独 作为 一 节 来 进行 讨论 。 下 面 还 会 讨论 虚拟 空间 管理 ， 但 是 将 会 以 用 户 空 间 
为 主 。 

1. 内 核对 于 内 存 的 管理 和 使 用 的 整体 框架 

Linux 内 核 的 内 存 管理 也 要 满足 内 核 自 身 的 需要 。 管 理 同样 会 有 粒度 问题 ， 作 为 现代 操 
作 系 统 通常 地 址 映射 都 是 以 页 为 单位 ， 这 样 进行 物理 内 存 管理 以 页 为 单位 是 比较 合适 的 。 内 
核 各 个 模块 所 需要 的 数据 大 小 不 同 ， 直 接 对 页 进行 操作 并 不 实际 ， 并 且 容 易 产生 碎片 ， 所 以 
需要 更 合理 的 分 配方 式 。 男 外 内 核 各 个 模块 中 又 有 很 多 固定 大 小 的 数据 结构 需要 进行 分 配 、 
释放 。 由 于 需要 频繁 的 分 配 、 释 放 相 同类 型 的 数据 ， 所 以 一 个 好 的 管理 方式 为 ， 将 它们 集中 
起 来 形成 池 ， 这样 对 于 提高 效率 和 减少 碎片 并 且 cache 都 是 有 好 处 的 。 这 些 都 需要 针对 内 核 
的 内 存 管理 提供 完整 的 框架 。 图 4-32 展示 了 Linux 内 核 的 内 存 管理 框架 。 

Al 4-32 的 最 底层 page allocator 是 对 物理 内 存 进行 管理 的 模块 ， 负 责 管理 所 有 的 物理 内 
存 ， 其 分 配 和 释放 的 都 是 以 页 (page) 为 单位 、 大 小 是 2^N 个 连续 的 物理 内 存 页 。 所 有 的 内 
存 管理 都 是 以 page allocator 为 基础 的 ， 其 采用 的 算法 为 经 典 的 Buddy (伙伴 算法 ) ， 当 然 不 
排除 以 后 会 有 更 好 的 算法 替代 ， 目 前 来 看 Buddy 还 是 很 好 地 完成 了 任务 。 仅 有 好 的 页 分 配器 
是 不 能 满足 内 核对 于 内 存 管 理 的 需要 的 ， 前 面 已 经 介绍 了 ， 内 核 有 很 多 频繁 使 用 的 数据 结 
构 ， 对 于 它们 最 好 单独 分 配 空间 进行 管理 ， 这 就 形成 了 SLAB 分 配器 (kmem_cache) 。 从 接 
口 名 字 kmem_cache 可 以 看 出 该 分 配器 还 有 作为 数据 结构 cache 的 功能 ， 其 实 将 相同 数据 结 
构 放 到 一 起 管理 本 身 就 减少 了 遍历 内 存 区 域 的 费时 操作 ， 从 这 个 角度 说 相当 于 cache 的 功 
能 。 关 于 SLAB 分 配器 ，Linux 内 核 提 供 了 SLUB 和 SLOB 两 种 更 轻便 的 分 配器 实现 ， 相 同 的 
功能 为 不 同类 型 的 设备 使 用 。 解 决 了 经 常 使 用 的 数据 结构 ，Linux 内 核 中 还 会 有 单独 驱动 使 
用 的 数据 结构 ， 以 及 那些 并 不 经 常 使 用 的 数据 结构 进行 分 配 和 管理 的 需求 。 为 这 些 数 据 结 构 
建立 kmem_cache 显然 是 一 种 浪费 ， 但 是 kmem_cache 又 有 这 些 优点 ， 最 好 能 够 使 用 ， 这 样 
内 核 针对 应 用 就 建立 一 组 匿名 的 SLAB cache， 将 一 组 特定 大 小 的 内 存 组 织 在 一 起 形成 kmem 
_cache。 由 于 并 不 是 针对 特定 的 数据 结构 而 是 特定 大 小 (是 2^N 个 字 节 ， 一 般 最 小 16B， 最 
多 2 page, 再 大 的 话 就 使 用 页 分 配器 了 ) ， 所 以 是 匿名 的 SLAB cache， 对 这 些 空间 分 配 的 
接口 是 kmalloc。 

以 上 讨论 的 内 存 管理 接口 获得 的 内 存 物 理 空 间 连 续 ， 并 且 进 行 映 射 时 虚拟 空间 也 是 连续 
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Some kernel Code 
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kmalloc allocator 
Uses a set of anonymous 














SLAB caches vmalloc Allocator 
Non-physically contiguous 
| memory 


SLAB Allocator 
Allows to create caches,each cache storing 


objects of the same size. Size can be lower or 
greater than a page size. 


Page Allocator 
Allows to allocate contiguous areas of physical pages(4k,8k, 16k,32k,etc) 


图 4-32 Linux 内 核 内 存 管理 框架 











的 ， 具体 到 内 核 地 址 映射 的 区 域 是 属于 low memory 的 部 分 。 内 核 部 分 只 有 这 种 内 存 管理 模 
式 是 不 够 的 ， 当 Linux 内 核 运 行 比较 长 的 时 间 后 仍 要 分 配 比较 大 的 内 存 ， 如 加 载 一 个 新 的 内 
核 模块 需要 的 空间 等 ， 此 时 很 可 能 已 经 没有 连续 的 物理 内 存 了 ， 而 系统 中 还 会 有 很 多 分 散 的 
内 存 〈 叫 内 存 外 部 碎片 ) 。 这 是 任何 算法 也 避免 不 了 的 ， 但 仍 要 想 办 法 将 这 部 分 内 存 空间 利 
用 起 来 。 内 核 提 供 了 相应 的 功能 就 是 vmalloc 分 配器 。vmalloc 分 配 右 提供 连续 的 虚拟 地 址 ， 
而 对 于 物理 页 是 可 以 不 连续 的 ， 这 样 就 在 很 大 程度 上 解决 了 内 存 外 部 碎片 的 问题 ， 也 为 各 种 
内 核 模块 提供 了 一 种 内 存 使 用 方法 (如 网 络 或 文件 系统 中 使 用 比较 大 的 内 存 )。 相 应 的 内 核 
虚拟 空间 就 是 vmalloc 空间 ， 注 意 其 中 使 用 的 物理 空间 还 是 以 页 为 单位 的 ， 自 然 相 应 的 虚拟 
空间 也 会 是 页 大 小 。 

接 下 来 看 看 kmem_cache 和 vmalloc 的 具体 实现 。 首 先 看 看 kmem_cache 的 实现 ， 对 于 
kmem_cache 的 slab 实现 通常 都 是 使 用 已 经 分 配 好 的 页 面 ， 但 是 需要 的 时 候 要 对 其 使 用 的 页 
面 进行 增长 ， 就 会 调用 kmem_getpages 来 获得 新 的 物理 页 面 直接 供 slab 使 用 。 看 看 kmem_ 
getpages 的 具体 实现 : 






































static void * kmem, getpages( struct kmem_cache * cachep, gfp_t flags, int nodeid) 
| 

struct page * page; 

int nr_pages; 


int 1; 
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// 根 据 kmem_cache 的 属性 标记 可 回收 属性 

flags E cachep — > gfpflags ; 

if( cachep —> flags & SLAB_RECLAIM_ACCOUNT) 
flags |= _ GFP. RECLAIMABLE; 











// 直 接 分 配 需要 的 所 有 连续 物理 页 面 ,如 果 分 配 不 到 就 直接 失败 
page = alloc_pages_exact_node( nodeid, flags | __GFP_NOTRACK, cachep -> gfporder) ; 

















if( ! page) 
return NULL; 


// 计 算 实际 分 配 的 页 数 

nr pages = (1 < cachep -> gfporder) ; 

// 根 据 kmem_cache 的 属性 标记 统计 物理 页 区 域 的 可 回收 页 
if( cachep —> flags & SLAB_RECLAIM_ACCOUNT) 








add_zone_page_state( page_zone( page) , 
NR_SLAB_RECLAIMABLE, nr_pages) ; 
else 
add_zone_page_state( page_zone( page) , 
NR_SLAB_UNRECLAIMABLE, nr_pages) ; 
// 设 置 所 有 相关 的 物理 页 管理 实体 ,标记 为 slab 使 用 


for(i =0; i<nr pages; i++ ) 























.. SetPageSlab( page +i); 


if( kmemcheck, enabled && ! (cachep -> flags & SLAB_NOTRACK) ) | 
kmemcheck_alloc_shadow( page, cachep —> gfporder, flags, nodeid) ; 


if( cachep —> ctor) 
kmemcheck_mark_uninitialized_pages( page, nr_pages) ; 
else 


kmemcheck_mark_unallocated_pages( page, nr pages); 


// 直接 返回 kmem. cache 需要 的 虚拟 地 址 
return page_address( page) ; 


| 


从 代码 中 可 见 ，kmem_cache 在 分 配 获得 物理 页 后 ， 并 没有 进行 映射 ， 而 是 直接 就 返回 
虚拟 地 址 了 。page_address 中 只 是 根据 物理 页 的 管理 实体 返回 正确 的 虚拟 地 址 ， 并 不 进行 地 
址 映射 的 操作 。 那 相应 的 地 址 映射 是 在 哪里 做 的 呢 ? 答案 是 初始 化 的 时 候 。 由 于 其 使 用 的 是 
low memory， 而 low memory 在 系统 初始 化 的 时 候 直 接 进 行 了 地 址 映射 ， 这 样 在 使 用 相应 空间 
时 就 不 需要 进行 地 址 映射 ， 从 而 大 大 地 提高 了 系统 效率 。 初 始 化 时 具体 映射 是 通过 map_ 
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lowmem 创建 的 。 代 码 细节 如 下 : 


static void — init map_lowmem( void ) 


struct memblock_region * reg; 


/ * Map all the lowmem memory banks. * / 
// 对 每 个 连续 的 内 存 块 进行 操作 


for_each_memblock( memory, reg) | 





phys_addr_t start = reg —> base; 
phys_addr_t end = start + reg —> size; 


struct map. desc map; 


if( end > lowmem, limit ) 
end = lowmem limit ; 
if( start >= end) 
break ; 
// 这 里 有 物理 地 址 和 虚拟 地 址 ,就 是 进行 映射 参数 的 设置 
map. pfn = phys_to_pfn( start) ; 
map. virtual = __ phys_to_virt( start) ; 
map. length = end — start; 
map. type = MT_MEMORY ; 
// 通 过 create_mapping 映射 low memory 范围 内 的 每 块 物理 内 存 


create_mapping( &map ) ; 





| 


接 下 来 看 看 vmalloc 的 实现 ， 看 看 有 什么 样 的 差别 。vmalloc 是 通过 ”vmalloc_node 建立 
AY, MRKŠE vmalloc node 的 逻辑 可 了 解 vmalloc 的 机 制 。 


static void * ^ vmalloc_node( unsigned long size, unsigned long align, 
gfp t gfp mask, pgprot_t prot, 


int node, void * caller) 


struct vm, struct. * area; 
void * addr; 


unsigned long real size = size; 


// 大 小 要 页 对 齐 

size = PAGE, ALIGN( size) ; 

if(!size || (size >> PAGE, SHIFT) > totalram, pages) 
return NULL; 
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// 这 里 先 要 从 vmalloe 的 虚拟 空间 中 ,把 虚拟 地 址 范围 (要 满足 大 小 ) 分 好 
area= get vm area node(size, align, VM_ALLOC, VMALLOC START, 
VMALLOC END, node, gfp mask, caller) ; 





if( Tarea) 
return NULL; 
// 根 据 虚拟 空间 的 大 小 分 配 页 面 (每 次 分 配 一 页 获得 需要 数目 的 页 面 ) ,并 做 映射 


addr = vmalloc_area_node( area, gfp mask, prot, node, caller); 

















/* 
* A ref count 23 is needed because the vm, struct and vmap, area 
* structures allocated in the — get. vm. area. node( ) function contain 
* references to the virtual address of the vmallo¢ ed block. 
*/ 


kmemleak, alloc( addr, real size, 3, gfp mask); 


return addr; 


| 


vmalloc 分 配 的 物理 页 面 究竟 映射 到 哪里 了 ? YE — vmalloc, area; node 中 会 调用 map_vm_ 
area 完成 映射 工作 ， 而 map. vm, area 最 终 会 调用 vmap_pud_range 来 完成 最 终 的 映射 工作 ， 
图 数 vmap_pud_range 中 可 见 相应 的 vmalloc 映射 的 页 目录 来 自 哪里 。 


static int vmap_pud_range(pgd_t * pgd, unsigned long addr, 


unsigned long end, pgprot t prot, struct page * * pages, int * nr) 


pud. t * pud; 


unsigned long next ; 


// 这 里 从 内 核 的 虚拟 空间 和 页 根 目录 管理 实体 中 分 配 页 目录 项 
pud = pud_alloc( &init mm, pgd, addr) ; 
if( ! pud) 
return — ENOMEM; 
// 进 行 实际 的 物理 页 映射 操作 ,会 调用 体系 结构 相关 代码 
do | 

















next = pud_addr_end(addr, end); 
if( vmap. pmd range( pud, addr, next, prot, pages, nr) ) 
return — ENOMEM; 
| while( pud ++ , addr =next, addr ! =end) ; 


return 0; 


| 


从 vmap_pud_range 中 可 见 ， 页 根 目录 来 自 于 init_mm。 在 初始 化 时 提 到 过 init mm, 但 
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是 并 没有 进行 详细 介绍 ， 现 在 可 以 详细 说 明了 。 对 于 页 目录 来 说 ,由 于 用 户 空间 是 和 任务 相 
关 的 ， 所 以 用 户 空间 每 个 任务 都 要 有 自己 的 页 目录 。 而 页 目录 本 身 从 不 同 的 体系 结构 来 说 ， 
并 不 是 都 支持 分 离 用 户 目录 和 内 核 目 录 的 ， 为 了 保持 一 致 性 Linux 内 核 使 用 页 根 目录 来 统一 
涵盖 用 户 空间 和 内 核 空 间 。 这 就 带 来 一 个 问题 ， 对 于 所 有 的 任务 ， 进 程 的 页 目录 中 内 核 地 址 
相关 的 部 分 应 该 是 相同 的 ， 这 该 如 何 实现 呢 ? 最 简单 的 方法 就 是 在 进程 创建 的 时 候 进 行 。 进 
程 创建 时 会 调用 体系 结构 相关 的 pgd_alloc， 而 ARM 体系 结构 下 会 将 其 定义 为 get_pgd_slow， 
这 里 就 分 配 页 根 目录 ， 并 将 内 核 的 地 址 空间 映射 进行 复制 。 














pgd_t * get pgd. slow(struct mm_struct * mm) 


| 


pgd_t * new pgd, * init pgd; 

pmd t * new pmd, * init, pmd; 

pte_t * new pte, * init, pte; 

// ARM 体系 结构 要 求 页 根 目录 (一 级 页 表 ) 大 小 为 16K, 所 以 order 为 2 
new_pgd=(pgdt * ) get free pages( GFP_KERNEL, 2) ; 

if( !new_ped) 





goto no_pgd; 
// 这 里 是 保护 ,需要 将 内 核 地 址 空间 重新 初始 化 
memset( new_pgd, 0, FIRST KERNEL PGD NR * sizeof(pgd_t) ) ; 




















/ * 
* Copy over the kernel and IO PGD entries 
*/ 
// 获 得 内 核 地 址 空间 的 页 根 目录 
init_pgd = pgd_offset_k(0) ; 
// 复 制 内 核 地 址 空间 的 页 目录 项 内 容 到 新 任务 进程 的 对 应 地 址 页 目录 项 中 
memcpy( new_pgd + FIRST_KERNEL_PGD_NR, init_pgd + FIRST_KERNEL_PGD_NR, 
(PTRS_PER_PGD - FIRST_KERNEL_PGD_NR) * sizeof( pgd t) ) ; 

















clean, dcache, area( new. pgd, PTRS_PER_PGD * sizeof( pgd t) ) ; 


// 对 于 向 量 表 是 低地 址 的 情况 ,由 于 起 始 地 址 是 0x0 ,所 以 需要 进行 特别 的 映射 操作 
if( lvectors_high( ) ) | 
/x 








* On ARM, first page must always be allocated since it 
* contains the machine vectors. 
*/ 

new. pmd = pmd. alloc( mm, new. ped, 0) ; 

if( !new_pmd ) 


goto no_pmd; 


new_pte = pte_alloc_map(mm, new_pmd, 0) ; 
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if( !new_pte) 


goto no_pte; 


init_pmd = pmd. offset( init, pgd, 0) ; 


init, pte = pte_offset_map(init_pmd, 0) ; 





set_pte_ext(new_pte, * init pte, 0) ; 
pte unmap( init, pte) ; 


pte unmap( new. pte) ; 


return new. pgd; 


no pte: 

pmd. free( mm, new. pmd) ; 
no. pmd : 

free. pages( (unsigned long) new. pgd, 2) ; 
no. pgd: 

return NULL; 


对 应 内 核 的 页 根 目录 (一 级 页 表 ) 的 获得 是 通过 宏 ped. offset. k 来 完成 的 ， 来 看 看 相应 





/* to find an entry in a kernel page — table — directory */ 


#define pgd. offset k( addr) pgd. offset( &init_mm, addr) 


又 见 到 init mm， 从 这 个 宏 中 可 以 明白 ，init_mm 就 是 管理 整个 内 核 虚拟 地 址 空间 的 实际 
管理 实体 。 相 应 的 也 会 包含 最 基本 的 内 核 地 址 空间 映射 的 页 根 目录 。 看 看 init mm 的 定义 : 


struct mm, struct init mm = | 








.mm rb =RB_ROOT, 

. pgd = swapper_pg_dir, 

. mm_users = ATOMIC_INIT(2) , 

. mm_count = ATOMIC INIT(1), 

.mmap sem = — RWSEM, INITIALIZER( init, mm. mmap. sem) , 

. page table lock = SPIN. LOCK. UNLOCKED( init. mm. page. table lock), 
. mmlist = LIST HEAD INIT( init mm. mmlist) , 

. cpu, vm. mask = CPU. MASK ALL, 


INIT. MM, CONTEXT Y( init, mm) 
F 





其 中 的 ped 就 是 页 根 目 录 ， 相 应 的 值 就 是 swapper_pg_dir。 对 swapper_pg_dir 应 该 并 不 
陌生 ， 在 讲 地 址 映射 中 已 经 提 到 了 ， 就 是 页 根 目 录 (一 级 页 表 ) 的 地 址 。ARM 体系 结构 是 
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在 物理 内 存 的 16 KB ~32 KB 空间 。 

关于 vmalloc 空间 还 是 要 多 说 一 些 ， 在 vmalloe 空间 中 相应 的 映射 并 不 是 像 low memory 
那样 只 要 初始 化 的 时 候 做 一 次 即 可 ， 而 是 需要 在 运行 时 动态 增 减 。 而 内 核 当 前 使 用 的 页 目录 
可 能 是 任何 任务 进程 的 页 目录 ， 这 就 需要 vmalloc 动态 创建 的 映射 最 终 也 能 保证 一 致 性 。 很 
直接 的 方法 是 在 创建 vmalloc 映射 时 ， 更 新 所 有 进程 相应 的 内 核 地 址 空间 页 目录 项 ， 但 是 很 
低 效 ， 而 内 核 只 有 在 需要 时 (通过 缺 页 异常 实现 ) 才 对 进程 的 内 核 地 址 空间 相关 目录 项 进 
行 同步 操作 。 具 体 实现 中 可 见 ，vmalloc 中 实际 的 映射 操作 还 是 针对 init mm 进行 ， 保 证 内 核 
地 址 空间 管理 实体 的 正确 性 。 当 内 核 使 用 那些 没有 同步 的 进程 页 表 访 问 相 应 的 vmalloc 空间 
时 会 发 生 data abort, Æ ARM 体系 结构 下 ， 相 应 的 data abort 最 终 会 调用 do_translation_fault。 
在 do, translation, fault 中 对 于 内 核 地 址 vmalloc 空间 发 生 的 data abort 最 终 会 执行 下 面 的 语句 : 



































// 根 据 地 址 获得 页 目录 项 偏 移 
index = ped. index( addr) ; 








J * 
* FIXME; CP15 Cl is write only on ARMv3 architectures. 
*/ 
// 根 据 处 理 器 的 寄存 器 获得 要 操作 的 页 目录 项 
pgd = cpu. get, ped( ) + index; 
// 获 得 内 核 地 址 空间 的 管理 实体 的 页 目录 项 
pgd_k = init mm. ped + index; 














if( pgd. none( * pgd_k) ) 


goto bad_area; 


if( !ped_present( * pgd) ) 
set_pgd(pgd, * pgd_k) ; 

// 获 得 二 级 页 表 

pmd_k = pmd_offset( pgd_k, addr) ; 

pmd =pmd_offset( ped, addr) ; 





index = (addr >> SECTION_SHIFT) & 1; 
if( pmd_none( pmd, k[ index ] ) ) 


goto bad_area; 





cm 


/ L5 Wifi BARAT AL i 
copy. pmd( pmd, pmd k) ; 


return 0; 


至 此 Linux 内 核 的 虚拟 地 址 空间 就 保证 了 一 致 性 。 当 然 由 于 Linux 内 核 在 切换 进程 时 要 
切换 一 级 页 表 ， 所 以 相同 vmalloc 的 访问 ， 可 能 发 生 不 止 一 次 的 访问 异常 。 但 是 这 些 都 是 在 
需要 的 时 候 才 进行 ， 相 对 来 说 开销 较 小 ， 是 一 种 高 效 的 实现 方式 。 
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以 上 介绍 了 内 核 中 主要 的 使 用 内 存 的 方法 及 相关 的 细节 。 下 面 总 结 一 下 ， 对 内 存 的 使 
用 ， 基 本 的 步骤 就 是 要 通过 Page Allocator 获得 需要 的 页 面 ， 并 需要 有 内 核 地 址 空间 的 映射 。 
复杂 的 映射 流程 会 影响 系统 效率 ， 所 以 对 于 kmem_cache 使 用 的 是 low memory 部 分 的 线性 映 
射 , 采用 的 办 法 是 在 初始 化 时 映射 ,减少 系统 运行 时 的 映射 步骤 ， 从 而 提高 效率 ; 而 vmal- 
loc 使 用 的 是 vmalloc 空间 的 映射 方式 ， 通 过 对 分 散 物理 页 面 运行 时 的 映射 减少 外 部 碎片 ， 另 
外 还 有 大 容量 内 存 的 high mem 部 分 的 kmap 映射 方式 也 是 可 行 的 。 用 户 空间 内 存 的 使 用 ， 内 
核 采 用 类 似 于 vmalloc 的 方式 进行 ， 首 先 获得 虚拟 地 址 空间 ， 后 分 配 页 ， 然 后 再 映射 到 用 户 
的 地 址 空间 ， 只 是 用 户 空 间 需 要 的 物理 内 存 页 ， 并 不 能 直接 满足 用 户 的 最 大 需求 ， 而 是 采取 
最 小 分 配 和 尽量 延迟 实际 分 配 的 方法 ， 只 有 在 不 得 不 进行 实际 物理 空间 的 分 配 时 才 会 进行 分 
配 。 这 其 中 不 仅 涉 及 物理 内 存 管理 还 涉及 地 址 映射 相关 的 处 理 器 异常 ， 这 些 紧 密 结 合 才能 完 
成 相应 的 工作 。 用 户 虚拟 空间 的 管理 及 内 存 使 用 ， 本 节 的 后 面 会 有 详细 介绍 。 

2. 内 核对 于 物理 内 存 管理 的 整体 框架 

从 前 面 的 介绍 可 以 看 出 ， 物 理 内 存 的 管理 主要 的 工作 都 集中 在 Page Allocator E, Page 
Allocator 负责 内 存 的 组 织 和 管理 。 说 到 内 存 的 组 织 和 管理 ， 就 既 要 考虑 用 户 空间 的 需求 同样 
要 考虑 内 核 空 间 的 需求 ， 对 内 核 来 说 效率 是 很 重要 的 一 部 分 功能 。 如 何在 内 存 管理 上 提高 效 
率 呢 ? 这 就 要 回 过 头 来 考虑 映射 ， 对 于 内 核 来 说 进行 线性 映射 是 提高 效率 的 重要 方法 ， 这 样 
对 于 频繁 访问 的 数据 ， 无 论 需要 物理 地 址 还 是 虚拟 地 址 都 可 以 进行 直接 的 线性 运算 来 完成 ， 
而 不 需要 进行 页 表 的 查询 以 及 负责 的 结构 进行 转换 ， 所 以 对 内 核 使 用 高 频 的 数据 进行 线性 映 
射 是 提高 效率 的 好 方法 。 而 内 核 地 址 空间 是 有 限 的 ， 且 现 有 的 内 存 基 本 都 超出 了 32 位 的 内 
核 地 址 空间 的 大 小 ， 所 以 需要 对 物理 内 存 进行 合理 的 组 织 来 满足 内 核 以 及 特殊 设备 的 需求 。 
图 4-33 展示 了 Linux 内 核 如 何 组 织 和 管理 物理 内 存 的 。 
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从 图 4-33 中 可 见 ，Linux 内 核 是 如 何 对 物理 内 存 进 行 组 织 的 。Linux 内 核 的 这 种 内 存 组 
织 适用 于 各 种 体系 结构 。 首 先 看 到 的 是 memory node， 每 个 memory node 就 是 一 个 或 者 一 组 
cpu (SMP) 可 以 访问 的 本 地 内 存 。 如 果 多 个 memory node 就 表示 有 多 组 cpu 每 组 都 有 本 地 内 
存 ， 而 多 组 cpu 以 及 相应 的 本 地 内 存 通过 高 速 总 线 互 连 ， 对 应 的 体系 结构 属于 NUMA 架构 ， 
对 应 于 某 个 cpu 来 说 访问 不 同 的 memory node ee 所 以 memory node 其 中 有 访 
问 成 本 的 概念 在 里 面 。 nes ee SoC 来 说 只 有 一 个 memory node (这 属于 UMA 架构 ) , 
也 就 是 说 无 论 是 单 cpu 还 是 SMP， 只 有 本 地 内 存 。 X Td ER EHE RIMIS 
域 即 zone, zone 的 划分 是 和 需求 分 不 开 的 ， 主 要 还 是 为 了 相应 的 效率 和 内 核 映 射 以 及 设备 的 
各 种 需求 。 首 先是 DMA zone 这 部 分 区 域 ， 有 该 区 域 的 原因 主要 是 由 于 某 些 处 理 器 的 DMA 
访问 空间 有 物理 地 址 的 限制 ， 需 要 将 这 部 分 限制 的 物理 空间 单独 形成 一 个 区 域 就 是 DMA 
zone。 通 常 只 有 老 的 设备 有 该 限制 ，ARM 体系 结构 中 新 的 内 核 已 经 没有 该 区 域 ， 但 是 Linux 
内 核 为 了 广泛 的 适用 范围 还 是 保留 该 区 域 。 接 下 来 是 low memory zone 即 ZONE_NORMAL, 
这 部 分 的 物理 内 存 空 间 就 是 可 以 进行 线性 映射 的 空间 。 在 low memory zone 之 后 是 high memo- 
ry zone， 对 于 high memory zone 中 的 物理 内 存 页 可 以 映射 到 vmalloc 以 及 pkmap 的 地 址 空间 。 
对 于 使 用 DMA zone 和 high memory zone 分 别 需要 配置 CONFIG_ZONE_DMA 和 CONFIG _ 
HICHMEM，ARM 体系 结构 中 ，DMA 并 没有 限制 ， 所 以 不 需要 配置 CONFIG_ZONE_DMA, 
而 CONFIG_HIGHMEM 的 配置 和 物理 内 存 的 大 小 相关 ， 通 常 超过 768 MB 内 存 就 可 以 配置 
CONFIG. HIGHMEM, 

内 核 如 何 区 分 low memory 和 high memory 的 大 小 呢 ? 又 要 回 到 初始 化 的 阶段 ， 在 函数 
sanity_check_meminfo 中 可 见 以 下 代码 ; 




















#ifdef CONFIG_HIGHMEM 
if( — va( bank —» start) > vmalloc_min | 
.. va(bank -> start) < (void * ) PAGE. OFFSET) 
highmem = 1 ; 


bank -> highmem = highmem; 


/ * 
* Split those memory banks which are partially overlapping 
* the vmalloc area greatly simplifying things later. 
*/ 
if(.— va( bank —» start) < vmalloc min && 
bank -> size > vmalloc_min - va( bank —> start) ) | 
if( meminfo. nr. banks >= NR, BANKS) | 
printk( KERN. CRIT "NR. BANKS too low, " 
"ignoring high memory a" ) ; 
} else | 
memmove( bank +1, bank, 


( meminfo. nr banks —i) * sizeof( * bank) ) ; 
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meminfo. nr_banks ++ ; 


i++; 
bank[ 1 ]. size — =vmalloc_min-__ va( bank —» start) ; 
bank[1].start 2 pa(vmalloc_min-1) +1; 
bank[ 1]. highmem = highmem = 1; 
Jtt; 
| 
bank -> size = vmalloc_min — __ va( bank —> start) ; 


| 


#else 


bank -> highmem = highmem ; 


/* 
* Check whether this memory bank would entirely overlap 
* the vmalloc area. 
*/ 
if(.— va( bank —» start) >= vmalloc_min | 
.. va(bank —> start) < (void * )PAGE_OFFSET) | 
printk ( KERN. NOTICE "Ignoring RAM at 96. 8lx — 96. 8lx " 


" ( vmalloc region overlap). \n" , 





bank -> start, bank -> start + bank —» size - 1) ; 


continue ; 


/x 
* Check whether this memory bank would partially overlap 
* the vmalloc area. 
*/ 
if(__ va( bank -> start + bank —> size) > vmalloc min || 
.. va(bank —> start + bank —» size) < — va( bank —> start) ) | 
unsigned long newsize = vmalloc min - — va( bank —> start) ; 
printk( KERN. NOTICE " Truncating RAM at 96. 8lx — 96. 8lx " 
"to — 96. 8lx( vmalloc region overlap). Wn" , 


bank -> start, bank —> start + bank —» size — 1 





, 


bank —> start + newsize — 1) ; 
bank —> size = newsize; 


| 
#endif 


从 这 段 代码 可 见 ， 只 有 在 设置 CONFIG_HIGHMEM 时 才 会 有 high memory 的 区 域 ， 主 要 

的 功能 是 使 得 low memory 的 大 小 在 进行 直接 线性 映射 后 不 能 进入 vmalloc 的 空间 ， 这 样 保证 

映射 的 正确 性 ， 如 果 定 义 了 CONFIG_HIGHMEM， 则 将 超出 的 部 分 归 入 high memory 的 区 域 ， 
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否则 忽略 相应 的 物理 空间 。 从 代码 可 见 vmalloc 的 设置 对 于 low memory 所 占 的 空间 是 有 影响 
的 ， 通常 只 有 物理 内 存 的 容量 大 并 且 CONFIG_HIGHMEM 设置 才 会 有 high memory 的 空间 。 
当然 可 以 在 CONFIG_HIGHMEM 设置 的 情况 下 ， 通 过 启动 参数 “vmalloc = ”改变 vmalloc We 
射 空间 的 大 小 ， 进 而 来 改变 low memory 所 占 空间 的 大 小 。 当 然 也 不 能 任意 减少 low memory 
的 空间 ， 至 少 还 要 给 low memory 保留 32 MB 的 空间 。 对 vmalloc 空间 的 限制 可 在 early_vmal- 
loc 中 找到 。 
Linux 系统 中 normal zone 是 必需 的 ， 而 high zone 的 使 用 与 否 是 和 物理 内 存 的 大 小 相关 
的 。 拥 有 大 物理 内 存 的 系统 通过 配置 CONFIG_HIGHMEM 可 以 使 能 相应 的 功能 ， 并 使 用 相应 
的 区 域 。 般 入 式 设备 ， 特 别 是 拥有 视频 能 力 的 设备 通常 都 有 比较 大 的 内 存 ， 就 需要 配置 
CONFIG_HIGHMEM 来 使 用 high zone 的 空间 。 其 实 ， 内 核 留 了 一 个 门 ， 可 以 在 内 存 并 不 多 的 
情况 下 使 用 high zone 的 方式 进行 内 存 管理 。 这 个 门 就 是 前 面 通过 配置 CONFIG_HIGHMEM 
并 对 vmalloc 进行 设置 来 实现 的 ， 当 vmalloc 的 设置 size 足够 大 ， 而 压缩 的 low memory 空间 只 
要 小 于 物理 内 存 的 大 小 ， 就 会 有 一 部 分 空间 放 入 high zone 的 管理 区 域 。 但 是 要 明确 两 个 空 
间 的 管理 效率 是 不 同 的 ，low memory 的 减少 会 造成 映射 开销 的 加 大 ， 从 而 降低 效率 ， 特 别 是 
内 核 需 要 很 多 空间 来 实现 数据 结构 的 cache 功能 。 所 以 在 内 存 不 足够 大 的 情况 下 没有 必要 规 
划 high zone 的 空间 。 
normal zone 和 high zone 的 物理 空间 究竟 是 如 何 使 用 的 ， 如 图 4-34 所 示 。 
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图 4-34 Linux 内 核 物理 内 存 zone 的 使 用 框 民 


图 4-34 左 侧 的 部 分 是 以 ARM 体系 结构 为 基础 的 内 核 映射 空间 分 配 框 图 ， 从 中 可 见 nor- 
mal zone 的 空间 主要 还 是 为 low memory 这 种 线性 映射 服务 的 ， 但 是 同样 还 会 为 vmalloc 服务 。 
而 high zone 则 不 会 映射 到 low memory 的 空间 ， 对 内 核 来 说 是 作为 补充 使 用 。vmalloc 的 空间 
中 分 配 物 理 内 存 的 操作 既 可 以 从 high zone 的 空间 也 可 以 从 normal zone 的 空间 获取 ， 如 果 两 
个 空间 都 存在 的 话 ， 分 配 就 要 有 一 个 先后 顺序 ， 这 个 顺序 就 是 : 先 使 用 high zone 的 空间 ， 
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然后 再 使 用 normal zone 的 空间 ， 原 因 在 于 normal zone 对 内 核 本 身 来 说 是 效率 最 高 的 物理 空 
间 ， 相 关 的 空间 在 可 以 的 情况 下 尽量 留 给 内 核 使 用 。 注 意 用 户 空间 需要 的 物理 内 存 分 配 同样 
会 进行 所 需 区 域 的 标记 ， 只 是 这 种 标记 是 通过 属性 宏 设 定 的 。 

对 物理 内 存 的 分 配 ， 如 何 标 记 这 种 区 域 的 顺序 呢 ?” 比 如 说 先 从 high zone 的 内 存 区 域 进 
行 分 配 等 ， 对 物理 内 存 管理 区 域 的 选择 通过 gfp_zone 和 first_zones_zonelist 来 实现 ， 详 细 的 代 
人 码 如 下 : 




















static inline enum zone_type gfp_zone( gfp_t flags) 


| 





enum zone. type Z; 


int bit 2( force int) (flags & GFP. ZONEMASK) ; 


z -(GFP. ZONE. TABLE >> (bit * ZONES SHIFT) ) & 
((1« ZONES. SHIFT) -1); 


if( —builtin constant, p( bit) ) 
MAYBE, BUILD. BUG. ON( ( GFP. ZONE. BAD >> bit) & 1) ; 
else | 
#ifdef CONFIG. DEBUG. VM 
BUG ON((GFP ZONE BAD >> bit) & 1) ; 
#endif 
| 


return Z; 


static inline struct zoneref * first_zones_zonelist( struct zonelist * zonelist, 
enum zone, type highest zoneidx, 
nodemask, t * nodes, 


struct zone * * zone ) 


return next zones zonelist(zonelist —». zonerefs, highest zoneidx, nodes, zone); 


| 


其 中 first_zones_zonelist 会 获得 一 个 物理 内 存 区 域 的 数组 ， 按 照相 应 的 顺序 来 试图 获得 
物理 页 ， 而 gfp zone 是 检查 物理 内 存 需求 属性 ， 根 据 相 应 的 属性 获得 首先 应 该 检查 的 物理 内 
存 区 域 。 这 里 涉及 一 个 重要 的 宏 定 义 就 是 CGFP_ZONE_TABLE ， 其 内 容 如 下 : 








#define GFP_ZONE_TABLE( \ 








(ZONE NORMAL «<0 * ZONES SHIFT) \ 
| (OPT ZONE DMA «< _GFP_DMA * ZONES_SHIFT) \ 
| (OPT ZONE HIGHMEM << . GFP HIGHMEM * ZONES_SHIFT) \ 
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(OPT_ZONE_DMA32 <<__ GFP_DMA32 * ZONES_SHIFT) \ 
(ZONE_NORMAL <__ GFP_MOVABLE * ZONES SHIFT) b 

(OPT ZONE DMA < (__ GFP_MOVABLE | __GFP_DMA) * ZONES SHIFT) \ 
(ZONE MOVABLE««( GFP MOVABLE| | GFP HIGHMEM) * ZONES SHIFT) V 
(OPT ZONE DMA32 << (__ GFP MOVABLE | .. GFP. DMA32) * ZONES SHIFT) V 





) 





从 中 可 以 看 到 很 多 以 _GFP 开头 的 属性 说 明 ， 这 些 属 性 都 是 在 内 存 管理 中 ， 对 应 着 不 同 
的 内 存 管 理 区 域 ， 如 _GFP_DMA、_GFP_HICHMEM 和 GFP. DMA32, X} T GFP_ZONE_ 
TABLE， 所 在 位 越 低 ， 就 越 重 要 ， 所 以 ZONE NORMAL 是 在 最 低位 。 对 于 以 ”GFP 开头 的 
属性 中 ， 这 里 没有 看 到 ”GFP_NORMAL， 因 为 对 于 Linux 内 核 来 说 不 标记 就 是 使 用 normal 
zone 的 区 域 。 另 外 需要 注意 的 是 OPT_ZONE_DMA, OPT ZONE. HIGHMEM 和 OPT_ZONE_ 
DMA32 这 些 安 ， 由 于 取出 OPT 相应 的 区 域 是 否 存在 都 是 和 内 存 配 置 相关 的 ， 而 GFP_ZONE_ 
TABLE 本 身 应 该 不 受 内 核 配 置 的 影响 ， 这 就 需要 通过 这 些 宏 来 解决 。 比 如 说 没有 任何 配置 
的 情况 下 OPT_ZONE_DMA 和 OPT_ZONE_HIGHMEM 实际 都 是 配置 成 ZONE_NORMAL。 最 后 
可 见 特殊 的 属性 宏 GFP_MOVABLE， 为 什么 会 有 该 宏 呢 ?这 是 由 于 很 长 时 间 以 来 ， 物理 内 
存 的 碎片 一 直 是 Linux 的 弱点 之 一 。 尽 管 提 出 了 很 多 方法 ,但 一 直 没 有 合适 的 方法 能 够 既 满 
AE Linux 对 各 种 类 型 工作 的 性 能 需求 ， 同 时 又 对 其 他 模块 影响 最 小 。 直 到 内 核 2. 6. 24 开发 
期 间 ， 防 止 物理 内 存 碎片 的 方法 终于 加 入 内 核 。 相 应 的 方法 受到 文件 系统 碎片 处 理 的 启发 ， 
文件 系统 也 有 碎片 ， 其 碎片 问题 主要 通过 碎片 合并 工具 解决 ， 分 析 文 件 系统 ， 重 新 排序 已 分 
配 的 存储 块 ， 从 而 建立 较 大 的 连续 存储 区 。 理 论 上 ， 该 方法 对 物理 内 存 也 是 可 行 的 ， 但 相应 
的 方法 需要 物理 页 是 可 移动 的 ， 这 样 才能 通过 移动 来 解决 碎片 问题 。 但 是 由 于 内 核 使 用 的 物 
理 内 存 页 通常 是 不 能 移动 的 ， 所 以 要 通过 该 方法 解决 碎片 问题 ， 就 要 将 物理 页 分 开 考 虑 ， 分 
为 可 移动 的 和 不 可 移动 的 。 总 的 来 说 ， 内 核减 少 物理 内 存 碎 片 的 方法 是 试图 从 开始 就 尽 可 能 
防止 碎片 。 

内 核 的 反 碎 片 方法 ， 首 先是 要 按照 物理 页 的 属性 分 为 不 同 的 类 型 。 对 Linux 内 核 来 说 ， 
主要 是 三 种 不 同类 型 : 

Q 不 可 移动 页 。 在 内 存 中 有 固定 位 置 ， 不 能 移动 到 其 他 地 方 。 内 核 核心 分 配 的 大 多 数 
内 存 属 于 该 类 别 。 

© 可 移动 页 。 可 以 随意 地 移动 。 用 户 空 间 应 用 程序 的 页 属于 该 类 别 。 这 类 页 是 通过 动 
态 页 表 有 映射 的 。 如 果 它 们 复制 到 新 位 置 ， 只 要 相应 的 更 新 页 表 项 即 可 ， 而 应 用 程序 是 不 会 注 
意 到 发 生 的 事情 。 

@ 可 回收 页 。 也 属于 可 移动 页 ， 只 是 其 不 能 直接 移动 ,但 是 其 内 容 由 于 可 以 从 某 些 源 
来 重新 生成 ， 所 以 其 页 面 可 以 直接 释放 ， 来 释放 物理 内 存 页 ， 然 后 重新 分 配 物理 页 再 恢复 ， 
这 样 就 是 逻辑 意义 上 的 可 移动 。 映 射 的 数据 页 (其 映射 源 是 文件 系统 的 文件 ) 就 属于 该 类 
别 。 如 果 有 swap 分 区 ， 内 核 的 kswapd 守护 进程 会 根据 可 回收 页 访问 的 频繁 程度 ， 周 期 性 释 
放 此 类 内 存 。 这 是 一 个 复杂 的 过 程 ， 只 要 了 解 内 核 会 在 需要 的 时 候 进 行 可 回收 页 的 回收 来 释 
放 内 存 就 可 以 了 。 

反 碎 片 技术 就 是 在 分 配 的 时 候 考虑 到 这 些 页 的 属性 ， 比 如 不 可 移动 的 页 不 能 位 于 可 移动 
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区 的 中 间 ， 和 否则 就 无 法 从 该 内 存 区 域 获得 较 大 的 连续 物理 内 存 ; 而 可 移动 的 内 存 页 ， 由 


于 最 终 可 以 通过 移动 页 面 来 减少 碎片 ， 则 相应 的 限制 就 比较 少 。 基 本 的 思路 如 此 ， 具 体 的 算 
法 细节 就 不 讨论 了 。_GCFP_MOVABLE 就 是 相应 的 可 移动 属性 的 标识 。 需 要 注意 的 是 ， 这 些 








属性 都 是 附加 在 物理 区 域 上 的 逻辑 属性 ， 这 些 逻 辑 属性 的 页 面 本 身 也 可 以 组 织 成 附加 的 区 


域 ， 相 应 的 Linux 内 核 增 加 了 ZONE. MOVABLE 来 表示 其 中 的 页 面 都 是 可 移动 的 。Linux 内 


核 中 


设置 


fill, 
块 以 


up 
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可 移动 区 域 可 以 通过 启动 参数 kernelcore 或 者 movablecore 进行 设置 ， 两 者 的 差别 是 前 者 
的 是 不 可 移动 区 域 空间 的 大 小 ， 而 后 者 设置 的 是 可 移动 区 域 空间 的 大 小 。 
前 面 看 到 了 和 物理 内 存 区 域 相关 的 内 存 分 配属 性 安 。 物 理 内 存 管 理 是 Linux 内 核 的 基 
是 各 种 模块 需要 的 底层 模块 之 一 ， 所 以 相应 的 分 配属 性 宏 不 只 和 区 域 相关 ， 还 和 各 种 模 
及 分 配 优先 级 相关 的 属性 ， 相 应 的 属性 说 明 如 下 : 

e GFP WAIT 表示 分 配 内 存 的 请 求 可 以 中 断 。 也 就 是 说 ， 调 度 器 在 该 请 求 期 间 可 选择 
另 一 个 进程 执行 ， 或 者 该 请 求 可 以 被 另 一 个 更 重要 的 事件 中 断 。 分 配器 还 可 以 在 返回 
内 存 之 前 ， 在 队列 上 等 待 一 个 事件 (相关 进程 会 进入 睡眠 状态 ) 。 

e GFP HIGH 表示 请 求 非常 重要 ， 内 核 急 切 地 需要 内 存 时 设置 该 标识 ， 在 分 配 内 存 失 
败 可 能 给 内 核 带 来 严重 后 果 时 ( 比如 威胁 到 系统 稳定 性 或 系统 崩 演 ) ， 就 会 使 用 该 标 
志 。 注 意 这 个 high 并 不 是 high zone， 虽 然 名 字 相 似 , fH. GFP. HIGH 与 _GFP_HIGH- 
MEM 毫 无 关系 ， 请 不 要 弄 混 这 两 者 。 

e GFP IO 说 明 在 查找 空闲 内 存 期 间 内 核 可 以 进行 VO 操作 。 实 际 上 ， 这 意味 着 如 果 
内 核 在 内 存 分 配 期 间 需 要 换 出 页 ， 那 么 只 有 当 设 置 该 标识 时 ， 才 能 将 选择 的 页 写 和 人 
人 硬盘。 

© GFP FS 人 允许 内 核 执行 VFS 操作 。 在 与 VFS 层 有 联系 的 内 核子 系统 中 必须 禁用 该 标 
识 ， 因 为 这 可 能 引起 循环 递归 调用 导致 死 锁 。 

e GFP. NOWARN 在 分 配 失 败 时 禁止 内 核 故 障 警 告 ， 在 极 少数 场合 该 标志 有 用 。 

© GFP REPEAT 在 分 配 失败 后 自动 重 试 , 但 在 尝试 奉 干 次 之 后 会 停止 。 

e _GFP_NOFAIL 在 分 配 失败 后 一 直 重 试 ， 直 至 成 功 。 

e GFP_ZERO 在 分 配 成 功 时 ， 将 返回 页 填充 字 节 0。 

e_GFP_HARDWALL 只 在 NUMA 系统 上 有 意义 。 它 限制 只 在 分 配 到 当前 进程 的 各 个 
CPU 所 关联 的 结 点 分 配 内 存 。 如 果 进 程 允 许 在 所 有 CPU 上 运行 〈 默 认 情 况 ) ， 该 标志 
是 无 意义 的 。 只 有 进程 可 以 运行 的 CPU 受 限 时 ， 该 标志 才 有 效果 。 

e GFP THISNODE 也 只 在 NUMA 系统 上 有 意义 。 如 果 设 置 该 比特 位 ， 则 内 存 分 配 失 
败 的 情况 下 不 允许 使 用 其 他 结 点 作为 备用 ， 需 要 保证 在 当前 结 点 或 者 明确 指定 的 结 点 
上 成 功 分 配 内 存 。 

e GFP RECLAIMABLE fll GFP. MOVABLE 是 前 面 说 明 的 减少 碎片 机 制 的 属性 标识 。 
顾名思义 ， 它 们 分 别 将 分 配 的 内 存 标记 为 可 回收 的 或 可 移动 的 。 

这 些 是 属于 底层 的 属性 标识 ， 而 对 于 内 核 各 个 模块 通常 使 用 的 属性 则 是 以 上 属性 的 组 










































































， 具 体 的 信息 见 gp.h， 常 用 的 重要 的 属性 宏 定 义 如 下 : 


#define GFP_ATOMIC (__ GFP_HIGH) 
#define GFP_NOIO  (__ GFP_WAIT) 

















#define GFP_NOFS (__ GFP_WAIT | GFP_IO) 

#define GFP. KERNEL (__ GFP_WAIT |__ GFP IO|  GFP FS) 

#define GFP_LTEMPORARY(__ GFP_WAIT | ___ GFP_IO | ___ GFP_FS | \ __ GFP RECLAIMABLE) 

#define GFP_USER  (__GFP_WAIT | GFP IO| GFP FS| GFP_HARDWALL) 

#define GFP_HIGHUSER (_ GFP_WAIT| GFP_IO| GFP_FS| _ GFP_HARDWALL | \ __ 
GFP_HIGHMEM) 

#define GFP_HIGHUSER_MOVABLE ( GFP WAIT| GFP IO| GFP_FS|\ 


GFP_HARD- 





WALL| GFP_HIGHMEM | \__ GFP_MOVABLE) 


#define GFP_IOFS(__ GFP_IO | GFP_FS) 





不 同 区 域 的 物理 内 存 管理 是 通过 伙伴 算法 实现 的 ， 具 体 如 图 4-35 所 示 。 
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4-35 Linux 内 核 物理 内 存 伙伴 算法 系统 框图 
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由 图 4-35 可 见 ， 整 个 Linux 内 核 的 内 存 管理 框架 是 以 区 域 进行 管理 的 ， 每 个 区 域内 部 
使 用 伙伴 系统 (buddy system) 将 物理 页 以 2 的 N 次 寡 的 连续 物理 页 进行 管理 ， 每 个 寡 次 单 
独 组 成 空闲 链表 。 对 某 个 内 存 区 域 的 物理 页 分 配 就 是 找到 合适 的 需 次 链表 ， 分 配 相应 的 连续 
物理 页 ， 如 果 相 应 寡 次 空闲 链表 是 空 ， 则 从 高 索 次 的 空闲 链表 中 拆 分 出 合适 的 物理 页 进行 分 
配 。 当 然 为 了 实现 反 碎 片 技术 ， 伙 伴 系 统 也 是 要 进行 相应 的 修改 ， 主 要 是 在 每 个 区 域 中 也 加 
入 页 类 型 的 管理 ， 相 应 的 空闲 链表 也 按照 相应 的 属性 组 织 ， 如 图 4-36 所 示 。 从 图 4-36 可 
见 ， 每 个 内 存 区 域 中 不 同 寡 次 的 空闲 链表 实际 是 数组 ， 每 个 项 是 一 种 类 型 的 页 面 ， 这 样 在 进 
行 分 配 和 释放 的 时 候 都 可 以 考虑 避免 内 存 碎片 的 问题 ， 从 而 实现 反 碎片 的 完整 方案 。 具 体 的 
算法 就 不 详细 讨论 了 

















Order 


2^1 0 zone-»free area[1 0]free iscMig ration Types... 


2 ^ 9 zone->free_area[9].free_list|M ig ration Ty pes... 


2 A 8 zone->free_area[8].free_list|M ig ration Ty pes... 


2^7 zone-»free area[7]free iisMigration Types... 


2 A 6 zone->free_area[6].free_list|M ig ration Ty pes... 


2^5 zone-»free area[D]free iisMigration Types... 


2 A 4 zone->free_area[4].free_list|M ig ration Types wat 


2 A 3 zone-»free area[À].free iisi]/M ig ration Types eee 


2 A 2 zone->free_area[2].free_list|M igration Types. zt 


2 A 1 zone-»free area[1 ]free isi M ig ration Types. ae 


240 zone->free_area[Q].free_list{Migration Types... 





Al 4-36 内存 zone 管理 反 碎 片 实现 





物理 内 存 的 管理 还 要 考虑 的 部 分 就 是 初始 化 的 流程 ， 图 4-37 中 可 见 详 细 的 物理 内 存 管 
理 初始 化 流程 。 

从 图 4-37 中 可 见 ， 主 要 的 物理 内 存 管理 初始 化 是 分 为 两 部 分 进行 操作 的 ， 第 一 部 分 主 
要 是 建立 区 域 的 信息 即 内 存 node 及 其 中 的 zone 的 信息 ， 而 具体 的 空闲 页 管理 并 没有 进行 相 
在 这 一 部 分 中 主要 是 根据 启动 参数 以 及 内 核 体系 结构 相关 的 配置 ， 将 总 的 内 存 

息 进 行 整理 形成 合适 的 区 域 ， 另 外 系统 会 拿 出 一 部 分 页 来 供 初始 化 分 配器 bootmem 使 用 ， 
该 分 配器 很 简单 ， 使 用 位 图 管理 ， 进 行 初始 化 阶段 内 存 管理 ， 满 足 初始 化 第 一 部 分 操作 完 之 
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start_kernel(in init/main.c) 
setup_arch(in arch/arm/kernel/setup.c) 
paging_init(in arch/arm/mm/mmu.c) 
bootmem init(in arch/arm/mmi/init.c) 


arm bootmem free(in arch//arm/mmi/init.c) 


^N 
poo 00e 


\ 
init_currently_empty_zone(in mm/page_alloc.c) 


Would initiate Zone Free Area(Order 0-10)'s free list 
link-list and set nr freez0. 


mem init(in arch/arm/mm/init.c) 
free_all_bootmem(in mm/bootmem.c) 


free_all_bootmem_core(in mm/bootmem.c) 


N 
aote 


V 
_free_pages(in mm/page_alloc.c) 


Would free all boot memory and merge free pages to Zone Free 
Area(Order 0-10)’ s free_list link-list.(mr_free would>0) 


图 4-37 Linux 内 核 内 存 管理 初始 化 流程 图 





前 内 核 特别 的 分 配 内 存 的 需要 (如 启动 命令 行 的 保存 等 ) ;第 二 部 分 是 建立 每 个 内 存 区 域 的 
空闲 页 管理 信息 ， 根 据 之 前 关于 初始 化 的 介绍 ， 这 时 已 经 有 完整 的 系统 内 存 信 息 ， 并 建立 
了 相应 的 区 域 列 表 ， 用 于 实际 的 内 存 分 配 系统 ， 此 部 分 的 主要 工作 就 是 释放 相应 的 boot- 
mem 初始 化 分 配器 分 配 的 空间 ， 并 根据 物理 内 存 的 使 用 情况 建立 每 个 区 域 的 空闲 页 管理 
链表 。 在 第 二 部 分 完成 之 后 ， 整 个 系统 就 可 以 使 用 物理 内 存 管理 系统 (buddy system) 进 
行内 存 管理 了 。 

为 什么 要 分 两 部 分 进行 初始 化 呢 ? 主要 是 由 于 Linux 内 核 不 是 只 支持 简单 的 单 CPU 单 内 
存 的 框架 ， 还 要 支持 多 CPU 和 NUMA 等 复杂 的 框架 ， 这 样 会 对 物理 内 存 有 不 同 的 需求 。 面 
对 如 此 复杂 的 系统 ， 将 物理 内 存 管 理 分 开 两 部 分 进行 ， 就 可 以 适应 更 复杂 的 情况 。 如 多 
CPU 需要 每 个 CPU 分 配 一 定 的 物理 页 作为 CPU 特有 内 存 以 提高 效率 ; NUMA 要 了 解 不 同 的 
内 存 节点 及 其 区 域 以 了 解 完整 的 系统 物理 内 存 管理 布局 。 另 外 分 成 两 部 分 也 方便 未 来 系统 功 
能 增强 和 扩展 。 
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3. 内 核对 于 虚拟 地 址 管理 的 整体 框架 

了 解 了 物理 内 存 空间 管理 之 后 ， 就 要 进入 虚拟 地 址 空间 了 。 相 应 的 Linux 内 核 提 供 了 完 
整 的 虚拟 地 址 管理 框架 。 关 于 虚拟 地 址 空间 ， 在 地 址 映射 时 主要 介绍 了 内 核 空 间 ，32 位 系 
统 完整 映射 如 图 4-38 所 示 。 





Vector 
FixMap 


DMA 


Kernel Space 1GB 
VMalloc 


Low Memory 


Kernel Image 


KMap 


3GB 








图 4-38 32 位 系统 完整 映射 


从 图 4-38 可 见 ，32 位 系统 内 核 通 常 的 分 配 是 3 -1 分 配 (也 可 通过 配置 修改 成 2 -2 分 
Ac) 即 3 GB 的 用 户 空间 ，1 GB 的 内 核 空间 。 关 于 内 核 虚 拟 地 址 空间 映射 部 分 在 第 4. 2 PE 
经 进行 了 详细 的 介绍 ， 接 下 来 主要 介绍 用 户 空间 的 部 分 是 如 何 管理 的 。 

关于 用 户 虚 拟 地 址 空间 ， 首 先 明 确 它 是 运行 用 户 的 应 用 程序 形成 的 ， 所 以 与 用 户 程 
序 是 息息相关 的 。 考 虑 一 下 用 户 空间 都 包含 什么 功能 的 数据 ?” 其 中 要 加 载 可 执行 文件 ， 
而 可 执行 文件 就 有 不 同 的 区 域 划分 ， 如 代码 段 、 数 据 段 bss 段 等 ， 这 些 都 应 该 在 用 户 空 
间 中 有 所 体现 。 另 外 对 于 用 户 空 间 内 存 管 理 堆 和 栈 都 是 必 不 可 少 的 ， 也 要 有 所 体现 。 再 
有 一 部 分 就 是 文件 映射 等 相关 的 映射 部 分 。 针 对 用 户 虚 拟 地 址 空间 ， 内 核 的 整体 分 布 如 
图 4-39 所 示 。 

从 图 4-39 可 见 ， 代 表 用 户 程序 的 进程 管理 实体 task_struct 结构 中 ， 有 对 于 虚拟 地 址 空 
间 管 理 的 结构 实体 mm_struct (内 核 虚 拟 地 址 空间 也 有 相应 结构 的 管理 实体 init mm) ， 整 个 
的 用 户 虚拟 地 址 空间 都 在 mm_struct 的 掌握 之 中 。 不 同 的 进程 必然 由 不 同 的 mm, struct 来 管 
理 它 的 虚拟 地 址 空间 。 下 面 来 看 看 结构 mm_struct 的 具体 内 容 : 
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start_code 


图 4-39 用 户 虚拟 地 址 空间 整体 管理 分 布 





struct mm_struct | 
struct vm_area_struct * mmap; /* list of VMAs * / 
struct rb_root mm_rb; 


struct vm area struct * mmap_cache; / * last find_vma result * / 


unsigned long mmap_base; / * base of mmap area * / 
unsigned long task size; /'* size of task vm space * / 


unsigned long cached hole size; /* if non —zero, the largest hole below free area cache * / 


unsigned long free area cache; / * first hole of size cached, hole size or larger * / 
pgd t * pgd; 

atomic t mm users; /* How many users with user space? * / 

atomic_t mm, count; / * How many references to "struct mm, struct" (users count as 1) * / 


int map_count; / * number of VMAs * / 


struct rw_semaphore mmap_sem; 


spinlock t page table lock; / * Protects page tables and some counters * / 
unsigned long hiwater_rss ; / * High — watermark of RSS usage * / 
unsigned long hiwater vm; / * High — water virtual memory usage * / 


unsigned long total_vm, locked_vm, shared_vm, exec_vm; 


unsigned long stack_vm, reserved_vm, def_flags, nr_ptes; 
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unsigned long start_code, end_code, start_data, end_data; 
unsigned long start_brk, brk, start_stack; 


unsigned long arg_start, arg_end, env_start, env_end; 





struct linux_binfmt * binfmt; 
cpumask_t cpu. vm, mask ; 
/ * Architecture — specific MM context * / 


mm_context_t context; 
E 

从 mm, struct 的 结构 中 可 见 ， 其 中 包含 了 进程 虚拟 地 址 空间 的 管理 属性 (如 锁 、 引 用 计 
数 等 ) ， 以 及 各 个 部 分 的 地 址 快速 索引 。 但 是 只 有 地 址 是 不 够 的 ， 进 程 的 虚拟 地 址 空间 的 每 
个 部 分 的 数据 属性 及 其 操作 方法 也 是 不 同 的 ， 同 样 需要 相应 的 管理 实体 来 表示 。 另 外 仅 有 虚 
拟 地 址 的 管理 也 是 不 够 的 ， 进 程 相应 的 空间 还 是 要 映射 到 实际 的 物理 内 存 中 。 这 就 是 mm_ 
struct 中 最 重要 的 两 个 属性 mmap 和 pgd。 首 先 来 看 pgd，pdg 中 存放 的 是 进行 虚拟 地 址 到 物 
理 地 址 转换 的 体系 结构 相关 的 页 表 首 地 址 ，ARM 体系 结构 中 相应 的 就 是 一 级 页 表 的 首 地 址 。 
页 表 承 担 的 任务 就 是 将 和 进程 相关 的 虚拟 地 址 转换 到 物理 地 址 ， 由 于 和 进程 相关 所 以 放 入 
mm struct 中 进行 管理 是 合理 和 必需 的 。 物 理 内 存 管理 已 经 涉及 页 表 中 内 核 地址 空间 的 映射 
实现 部 分 ， 用 户 空间 的 映射 和 其 虚拟 地 址 中 存放 数据 的 属性 相关 。 由 于 各 种 数据 属性 的 差 
异 ， 属 于 个 体 属性 ， 而 转换 页 表 属 于 整体 属性 ， 这 也 在 形式 上 要 求 一 个 上 层 的 结构 管理 这 两 
部 分 属性 。Linux 内 核 中 这 个 上 层 的 结构 就 是 mm_struct。 管 理 进程 中 存放 不 同类 型 数据 的 虚 
拟 空 间 管理 结构 就 是 vm_area_struct, 在 mm_struct 中 由 mmap 对 vm_area_struct 统一 进行 管 


理 。 对 于 vm_area_struct 详细 的 内 容 如 下 : 







































































struct vm_area_struct | 
struct mm struct * vm mm; / * The address space we belong to. */ 
unsigned long vm_start; / * Our start address within vm mm. * / 


unsigned long vm_end; / * The first byte after our end address within vm mm. * / 


/ * linked list of VM areas per task, sorted by address * / 


struct vm_area_struct * vm_next, * vm_prev; 


pgprot_t vm_page_prot; / * Access permissions of this VMA. */ 


unsigned long vm. flags; /* Flags, see mm. h. */ 


struct rb. node vm rb; 


/* 


* For areas with an address space and backing store, 
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* linkage into the address space —» i mmap prio tree, or 

* linkage to the list of like vmas hanging off its node, or 

* linkage of vma in the address space -> i. mmap. nonlinear list. 

*/ 

union | 
struct | 

struct list. head list; 
void * parent;/ * aligns with prio tree node parent * / 
struct vm, area, struct. * head; 


| vm. set; 


struct raw, prio, tree node prio tree node; 


} shared; 





Ja 
* A filè s MAP_PRIVATE vma can be in both i_mmap tree and anon_vma 
* list, after a COW of one of the file pages. A MAP_SHARED vma 
* can only be in the i_mmap tree. An anonymous MAP_PRIVATE, stack 
* or brk vma( with NULL file)can only be in an anon_vma list. 
*/ 
struct list_head anon_vma_chain;/ * Serialized by mmap_sem & 
* page table lock * / 


struct anon. vma * anon. vma;/ * Serialized by page table lock * / 


/ * Function pointers to deal with this struct. * / 


const struct vm operations struct * vm ops; 


/ * Information about our backing store; */ 


unsigned long vm. pgoff; / * Offset( within vm file)in PAGE SIZE 
units, * not * PAGE CACHE SIZE */ 

struct file * vm file; /* File we map to(can be NULL). */ 

void * vm, private data; / * was vm, pte( shared mem) * / 


unsigned long vm, truncate count;/ * truncate count or restart addr * / 


#ifndef CONFIG_MMU 

struct vm, region * vm region; /* NOMMU mapping region * / 
#endif 
#ifdef CONFIG_NUMA 

struct mempolicy * vm_policy; / * NUMA policy for the VMA */ 
#endif 
1 
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对 于 结构 vm. area. struct 几 个 比较 重要 的 属性 如 下 : 

* vm_page_prot。 用 于 相应 虚拟 空间 页 表 的 体系 结构 相关 的 属性 。 

* vm_flags。 表 示 相 应 虚拟 空间 中 数据 的 逻辑 属性 ， 如 读 、 写 、 执 行 和 增长 以 及 操作 方 
式 等 。 

* vm_file。 用 于 文件 映射 的 虚拟 空间 ， 指 向 该 区 域 映射 的 文件 。 它 会 和 文件 系统 关联 。 

evm_ops。 所 管理 区 域 发 生 虚 拟 地 址 访问 异常 时 相应 操作 的 回调 函数 接口 。 内 存 管理 主 
要 是 缺 页 异常 操作 接口 。 

整体 的 Linux 内 核 中 对 用 户 进 程 虚拟 空间 的 管理 分 布 如 图 4-40 所 示 。 

---------- > vm_end :firstaddress outside virtual memory area 


— vm start: first address within virtual memory area 
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图 4-40 ”用 户 进程 虚拟 空间 的 管理 分 布 
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从 图 4-40 中 可 见 ， 可 执行 文件 、 各 种 类 型 虚拟 空间 以 及 文件 系统 的 整体 关系 。 这 样 对 
系统 会 有 一 个 整体 的 理解 。 
再 来 看 看 对 于 虚拟 地 址 映射 的 细节 ， 如 图 4-41 所 示 。 
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图 4-41 用 户 虚 拟 地 址 映射 细节 


从 图 4-41 中 可 见 ， 每 个 vm_area_struct 管理 的 虚拟 地 址 都 会 涉及 相关 的 页 表 项 ， 即 相 
应 虚拟 地 址 范围 内 的 页 表 项 。 而 相应 的 页 表 项 会 有 相关 的 访问 属性 ， 这 些 属 性 一 般 由 vm_ 
area_struct 中 的 vm. page. prot 来 进行 维护 ， 在 获得 具体 的 物理 页 之 后 再 与 访问 属性 结合 形成 
最 终 的 页 表 项 从 而 填 人 页 表 中 完成 最 终 的 映射 工作 。 对 用 户 空 间 的 物理 页 分 配 ，Linux 内 核 
同样 采用 将 操作 延 信 到 最 后 才 执 行 ， 这 样 就 会 涉及 地 址 访问 异常 ， 在 异常 处 理 中 ， 内 核 会 根 
据 确认 的 用 户 空 间 虚 拟 地 址 及 相应 的 进程 找到 合适 的 vm_area_struct， 其 中 的 vm_ops 会 进行 
合适 的 操作 来 完成 映射 需要 的 工作 。vm_ops 则 会 在 vm_area_struct 创建 的 时 候 根 据 相 关 的 数 
据 属 性 填 人 合适 的 操作 接口 。 

注意 vm_area_struct 也 为 系统 的 扩展 留 下 了 很 大 的 空间 。 进 程 中 的 虚拟 地 址 空间 是 用 户 
使 用 的 直接 接口 ， 而 虚拟 空间 中 具体 的 映射 内 容 可 以 是 各 种 内 容 ， 可 以 根据 需要 进行 扩展 ， 
这 部 分 的 扩展 主要 是 在 图 4-40 中 的 mapping 部 分 体现 。 作为 映射 ， 内 核 中 主要 就 是 文件 映 
射 ， 相 应 的 框架 如 图 4-42 所 示 。 
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图 4-42 文件 映射 框架 
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图 4-42 中 针对 文件 映射 的 虚拟 地 址 空间 由 address space 区 域 表 示 ， 为 什么 叫 address 
space? 需要 考虑 的 是 对 于 文件 来 说 也 可 以 抽象 为 一 种 地 址 空间 ， 而 文件 所 在 的 地 址 空间 相 
对 于 虚拟 地 址 空间 是 完全 不 同 的 地 址 空间 。Linux 内 核对 这 种 不 同 的 地 址 空间 抽象 为 
address space 进行 管理 ，address_space 的 详细 内 容 如 下 : 





struct address_space | 
struct inode * host; / * owner; inode, block device * / 
struct radix tree root page tree; / * radix tree of all pages * / 
spinlock t tree. lock;/ * and lock protecting it ** / 
unsigned int i_mmap_writable;/ * count VM, SHARED mappings */ 
struct prio tree root i mmap; / * tree of private and shared mappings * / 
struct list head i_mmap_nonlinear;/ * list VM_NONLINEAR mappings * / 
spinlock_t i_mmap_lock;/ * protect tree, count, list * / 
unsigned int truncate count; / * Cover race condition with truncate * / 
unsigned long — nrpages;/ * number of total pages * / 
pgoff t writeback index;/ * writeback starts here * / 
const struct address space operations ** a ops; / * methods */ 
unsigned long flags; / * error bits/gfp mask * / 
struct backing dev. info ** backing dev. info;/ * device readahead, etc */ 
spinlock t private lock;/ * for use by the address space * / 
struct list head — private list;/ * ditto */ 
struct address space * assoc_mapping;/ * ditto * / 


| attribute — ( (aligned(sizeof(long) ) ) ) ; 





address space 中 比较 重要 的 属性 就 是 a_ops， 其 中 主要 是 进行 文件 映射 的 操作 接口 ， 相 
应 的 会 将 文件 与 页 进行 关联 的 操作 。 比 如 当 文 件 映射 的 空间 发 生 访问 异常 的 时 候 ,， 会 通过 
a. ops 相关 的 操作 将 文件 合适 的 内 容 填 人 物理 页 ， 而 当 页 内 容 需 要 回 写 到 文件 的 时 候 也 会 通 
过 相应 的 接口 写 回 文件 ， 可 以 说 是 文件 和 页 之 间 的 转换 接口 。 在 i_mmap 可 以 找到 所 有 与 其 
相 关 的 vm, area, struct, 而 vm_area_struct 可 以 通过 其 中 的 vm_file 找 到 相 应 的 address_space 
这 样 就 将 address_space 和 vm_area_struct 完整 地 关联 起 来 。 

注意 映射 的 内 容 是 可 以 多 个 进程 共享 的 ， 所 以 会 有 一 个 问题 需要 处 理 ， 需 要 知道 哪些 物 
理 页 面 被 不 同 的 进程 通过 映射 来 使 用 了 。 进 程 映射 的 页 可 以 直接 通过 查找 页 表 确 认 ， 而 如 何 
通过 页 来 查找 使 用 的 进程 对 内 存 管理 来 说 也 是 很 重要 的 ， 这 是 由 于 页 换 出 时 需要 修改 所 有 相 
关 进 程 的 页 表 。 只 要 能 够 通过 页 来 找到 所 有 对 应 的 vm_area_struct 即 可 解决 相关 问题 。 先 来 
看 看 对 于 物理 页 内 存 的 管理 实体 struct page， 详 细 内 容 如 下 : 
































struct page | 
unsigned long flags; /* Atomic flags, some possibly 
* updated asynchronously */ 


atomic_t _count; / * Usage count, see below. **/ 


union | 


186 


struct | 
unsigned long private;/ * Mapping - private opaque data: 
* usually used for buffer_heads 
* if PagePrivate set; used for 
* swp.entry t if PageSwapCache; 
* indicates order in the buddy 
* system if PG. buddy is set. 
*/ 
struct address space * mapping; / * If low bit clear, points to 
* inode address space, or NULL. 
* If page mapped as anonymous 
* memory, low bit is set, and 
* it points to anon. vma object: 
* see PAGE MAPPING. ANON below. 
*/ 


EE 


从 中 看 到 了 struct address. space. * mapping， 这 样 加 上 之 前 address. space 到 vm, area - 
struct 的 通路 ， 就 可 以 通过 物理 页 找到 所 有 的 vm_area_struct， 解 决 相应 的 问题 。 相 对 于 文件 
映射 还 有 一 种 是 匿名 映射 ， 主 要 是 图 4-40 中 anonymous 的 部 分 。 相 应 的 反 向 查找 也 是 通过 
mapping 解决 的 ， 只 是 这 里 采用 了 小 技巧 ， 由 于 前 面 看 到 了 对 于 address space 是 要 保证 对 齐 
的 ， 所 以 低地 址 为 0， 可 以 通过 低地 址 进行 属性 标记 ， 这 里 对 匿名 映射 会 进行 标记 并 由 高 地 
址 指向 结构 anon, vma 来 查找 对 应 的 vm_area_struct， 从 而 解决 反 向 查找 的 问题 。 

4. 内 存 管 理 的 重要 参数 

Linux 内 核 内 存 管理 中 ， 内 核 提 供 了 相关 的 参数 ， 供 系统 管理 人 员 进 行 设置 ， 以 适用 不 
同 的 系统 并 提高 系统 的 效率 。 内 存 管理 重要 的 设置 参数 都 在 /proc/sys/vm 目录 下 : 

































































— admin_reserve_kbytes 

— block_dump 

— compact_memory 

— dirty_background_bytes 
— dirty_background_ratio 
— dirty_bytes 

— dirty_expire_centisecs 

— dirty_ratio 

— dirty_writeback_centisecs 
— drop_caches 

— extfrag_threshold 

— hugepages_treat_as_movable 


— hugetlb_shm_group 
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— laptop_mode 

— legacy. va. layout 

— lowmem, reserve, ratio 

— max map. count 

— memory. failure early kill 
— memory. failure recovery 
— min, free kbytes 

— min slab ratio 

— min, unmapped. ratio 

— mmap min addr 

— nr hugepages 

— nr overcommit hugepages 
— nr trim pages (only if CONFIG_MMU =n) 
— numa_zonelist_order 

— oom, dump. tasks 

— oom, kill allocating task 
— overcommit memory 

— overcommit ratio 

— page - cluster 

— panic on oom 

— percpu. pagelist, fraction 
— stat. interval 

— swappiness 

— user reserve kbytes 

— vfs cache pressure 


— zone reclaim. mode 


下 面 对 其 中 的 两 个 参数 进行 说 明 


D^ proc/sys/ vm/lowmem, reserve, ratio, EZA EC AMHA f XJ Linux 内 核 ， 通 常用 户 空间 
使 用 的 内 存 会 先 从 high memory 获得 ， 若 没有 才 会 在 low memory 中 获取 。 主 要 原因 在 于 内 核 








重要 的 数据 结构 (基于 kmalloc/kmem, cache) ， 都 会 从 有 限 的 low memory 空间 获取 。 这 样 可 


以 知道 lowmem_reserve_ratio 比较 适用 于 系统 中 有 大 块 high memory 的 情况 ， 若 系统 中 只 
low memory 区 域 ， 或 是 high memory 区 域 很 有 限 ， 设 定 这 个 参数 的 意义 就 不 会 太 大 。 若 希望 





确保 low memory 的 区 域 尽 可 能 不 要 被 能 使 用 high memory 的 请 求 给 分 配 走 ， 











就 该 把 lowmem_ 


reserve ratio 设 定 为 1( =100% ) 。 若 是 设 定 的 数值 越 高 ， 则 越 有 可 能 让 low memory 区 域 的 内 


存 分 配给 相应 的 请 求 使 用 。 





(2) /proc/sys/vm/max_map_count, mmap 相应 的 应 用 程序 地 址 空间 之 前 已 经 进行 了 介绍 ， 





max map. count 用 以 限定 单一 应 用 程序 执行 环境 中 最 大 的 mmap AY Be, 3 








RUER ETF DE- 


FAULT_MAX_MAP_COUNT。 除 非 资源 不 足 ， 否 则 上 默认 值 的 配置 已 能 符合 目前 应 用 程序 的 


其 他 参数 内 核 文档 中 有 详细 的 说 明 。 
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至 此 ，Linux 内 核 内 存 管理 的 主要 内 容 都 进行 了 介绍 。 
4.4.3 TI 芯片 内 存 管理 相关 实现 详解 


1. 芯片 片 内 内 存 使 用 

开 世 片 相关 的 内 存 管理 ， 对 片 外 内 存 来 说 ， 可 以 通过 启动 参数 将 需要 内 核 管理 的 内 存 
进行 设置 。 而 片 内 内 存 则 有 各 种 各 样 的 使 用 方式 ，DM 3730 芯片 是 将 其 直接 映射 到 内 核 虚拟 
地 址 空间 的 特定 地 址 以 供 使 用 ， 采 用 该 方法 的 原因 主要 是 由 于 电源 管理 很 多 功能 需要 片 内 内 











存 。 这 里 介绍 一 下 映射 前 
如 下 : 


了 分， 具体 的 使 用 则 在 芯片 电源 管理 部 分 进行 介绍 。 相 关 有 映射 代码 


static void — init omap_map_sram( void) 


unsigned long 


base; 


if( omap. sram, size == 0) 


return; 


if( cpu_is_omap34xx( ) ) | 


/ * 


* SRAM must be marked as non — cached on OMAP3 since the 


* COR 


E DPLL M2 divider change code(in SRAM) runs with the 


* SDRAM controller disabled, and if it is marked cached, 
* the ARM may attempt to write cache lines back to SDRAM 


* which will cause the system to hang. 


EA 


omap. sra 


m, io desc[ 0]. type - MT MEMORY. NONCACHED; 


omap. sram. io. desc[ 0]. virtual = omap. sram base; 


base = omap. s 


ram, start ; 


base = ROUND. DOWN(base, PAGE SIZE) ; 

omap. sram io desc[0]. pfn- . phys to pfn(base); 

omap_sram_io_desc[ 0]. length = ROUND DOWN( omap. sram size, PAGE SIZE) ; 
iotable  init( omap. sram, io. desc, ARRAY, SIZE( omap. sram io desc) ) ; 


printk( KERN, INFO "SRAM: Mapped pa 0x% 08lx to va 0x% 08lx size; 0x% lx Wn" , 


.. pfn to phys(omap. sram io. desc[0]. pfn), 


omap. sram, io, desc[ 0 ]. virtual, 


omap. sra 


Ve 
* Normally 


m_io_desc[ 0 ]. length) ; 


devicemaps, init( ) would flush caches and tlb after 
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* mdesc —>map_io(), but since we re called from map. io( ) , we 
* must do it here. 
*/ 

local, flush, tlb, all( ) ; 

flush, cache, all( ) ; 


/* 
* Looks like we need to preserve some bootloader code at the 
* beginning of SRAM for jumping to flash for reboot to work. . . 
*/ 
memset( (void * ) omap. sram, base + SRAM, BOOTLOADER, SZ, 0, 
omap. sram, size - SRAM, BOOTLOADER, SZ) ; 
} 





omap_map_sram 是 将 片 内 内 存 映 射 到 内 核 的 虚拟 地 址 空间 ， 使 用 的 方式 是 按照 TO 映射 
进行 的 ， 主 要 是 由 于 对 于 ARM 体系 结构 使 用 统一 的 地 址 ， 另 外 需要 关 掉 cache 进行 映射 ， 
映射 到 omap_sram_base (使 用 变量 是 因为 可 以 根据 芯片 调整 ) 指定 的 地 址 。 该 接口 是 在 板 
级 支持 的 map_io 中 被 调用 ， 这 样 DM 3730 内 核 就 可 以 直接 使 用 相应 的 虚拟 地 址 进行 操作 了 。 
使 用 相应 空间 的 接口 函数 是 omap_sram_push ， 详 细 代 码 如 下 : 

















void * omap_sram_push(void * start, unsigned long size) 
| 
if( size > (omap_sram_ceil — (omap_sram_base + SRAM_BOOTLOADER_SZ) ) ) | 
printk( KERN, ERR "Not enough space in SRAM\n" ) ; 
return NULL; 


omap. sram, ceil — = size; 

omap. sram, ceil = ROUND DOWN( omap. sram ceil, sizeof( void * ) ) ; 
memoepy( (void * )omap_sram_ceil, start, size) ; 

flush, icache range( (unsigned long) omap. sram  ceil , 


(unsigned long) (omap_sram_ceil + size) ) ; 


return( void * )omap_sram_ceil; 


| 


从 omap_sram_push 可 见 ， 其 采用 从 后 往 前 的 方式 进行 分 配 ， 主 要 是 将 需要 的 数据 复制 
到 相应 的 片 内 空间 。 世 片 电源 管理 部 分 可 知 具体 的 数据 内 容 ， 这 里 可 以 先 说 明 一 下 ， 其 内 容 
主要 是 执行 的 代码 。 

2. 芯片 保留 物理 内 存 

SoC 内 部 通常 有 些 模块 需要 在 启动 时 保留 部 分 内 存 空间 。 这 样 做 的 原因 是 由 于 需要 连续 
的 物理 内 存 空间 ， 并 且 对 内 核 的 物理 内 存 管 理 影响 最 小 。DM 3730 同样 有 该 需求 ， 看 看 DM 
790 














3730 是 如 何 实现 相应 功能 的 : 


// 该 接口 是 给 machine. desc 提供 的 board 板 级 memory reserve 的 接口 
// 其 中 vram_reserve 通过 bootargs 这 种 初始 化 vram 参数 的 方式 保留 空间 
//dsp_reserve 则 是 为 了 dsp_bridge 保留 空间 . 
void ^ init omap_reserve( void ) 
| 
omapfb reserve sdram, memblock( ) ; 


omap. vram reserve sdram memblock( ) ; 





omap. dsp. reserve. sdram. memblock ( ) ; 


| 





之 前 在 介绍 Linux 内 核 初 始 化 时 看 到 arm_memblock_init , 其 中 会 根据 启动 时 的 参数 获得 
物理 内 存 的 memblock 信息 ， 在 该 接口 中 会 调用 板 级 的 reserve 接口 ， 就 可 以 保留 内 存 空 间 ， 
使 得 Linux 内 核 不 管理 这 部 分 物理 内 存 ， 而 是 留 给 板 级 相关 的 驱动 去 管理 ， 这 就 相当 于 
Linux 内 核 开 出 一 块 保留 区 域 给 处 理 器 自由 使 用 。DM 3730 就 是 利用 该 接口 ， 保 留 了 相关 的 
内 存 ， 为 特殊 的 驱动 使 用 ， 包 括 显示 驱动 和 DSP 相关 功能 部 分 。 具 体 的 内 容 还 是 在 实际 驱 
动 中 进行 介绍 。 

3. 独立 cmem 管理 

之 前 简单 说 明 世 片 厂商 的 独立 内 存 管 理 ， 针 对 于 TI 的 视频 芯片 ，TI 提供 了 cmem 的 内 
存 管理 驱动 ， 主 要 是 连续 内 存 管理 。 其 主要 目的 是 针对 视频 SoC 的 视频 加 速 应 用 ， 如 视频 编 
解码 功能 。 视 频 编 解码 功能 通常 属于 应 用 的 范畴 ， 而 如 果 通 过 硬件 加 速 来 实现 视频 编 解码 ， 
则 其 需要 连续 的 物理 空间 ， 这 就 相当 于 要 在 应 用 中 使 用 连续 的 物理 内 存 。 如 果 由 Linux 内 核 
直接 管理 和 提供 这 部 分 内 存 是 无 法 实现 的 ， 这 样 蕊 片 厂商 就 开发 相应 的 驱动 ， 通 过 将 物理 内 
存 交 由 驱动 管理 ， 而 不 是 内 核 直 接管 理 来 实现 该 功能 。 具 体 的 映射 则 通过 虚拟 地 址 的 映射 机 
制 来 实现 。 

对 于 TI 的 cmem 有 两 种 分 配 模式 : 一 种 是 采用 pool 算法 实现 的 ， 通 过 参数 来 设 定 所 管 
理 的 物理 空间 的 地 址 范围 及 每 个 内 存 池 的 大 小 及 数目 ， 以 驱动 的 形式 管理 这 部 分 内 存 ; 另 一 
种 是 heap 模式 ， 把 内 存 区 域 作为 堆 来 使 用 。 这 两 种 模式 对 于 内 存 的 管理 都 是 通过 TO 控制 来 
完成 。 下 面 是 一 个 使 用 的 例子 : 
























































insmod cmemk. ko phys, start = 0x83200000 phys. end = 0x88000000 allowOverlap = 1 phys_start_1 = 
0x00001000 phys. end. 1 2 0x00008000 pools 1 = 1x28672 


这 个 例子 就 是 对 大 块 的 物理 内 存 使 用 堆 模 式 ， 而 对 于 片 内 的 内 存 采 用 了 pool 模式 管理 。 

当然 对 内 存 管理 不 可 忽视 的 是 处 理 需 cache 相关 的 操作 ， 为 了 给 相关 的 应 用 提供 完整 的 
功能 ， 独 立 的 内 存 管理 同样 也 要 提供 cache 相关 的 操作 接口 ， 对 于 cmem 提供 的 完整 操作 接 
HF. 











#define CMEM_IOCALLOC 1 
#define CMEM_IOCALLOCHEAP 2 
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#define CMEM_IOCFREE 3 

#define CMEM_IOCGETPHYS 4 

#define CMEM_IOCGETSIZE 5 

#define CMEM_IOCGETPOOL 6 

#define CMEM_IOCCACHE 7 

#define CMEM_IOCGETVERSION 8 

#define CMEM_IOCGETBLOCK 9 

#define CMEM_IOCREGUSER 10 

#define CMEM_IOCGETNUMBLOCKS 11 

#defineCMEM_IOCCACHEWBINV CMEM_IOCCACHE | CMEM_WB | CMEM_INV 
#define CMEM_IOCCACHEWB CMEM_IOCCACHE | CMEM_WB 
#define CMEM_IOCCACHEINV CMEM IOCCACHE | CMEM_INV 
#define CMEM_IOCALLOCCACHED CMEM_IOCALLOC | CMEM_CACHED 
#define CMEM_IOCALLOCHEAPCACHED CMEM_IOCALLOCHEAP | CMEM_CACHED 
#define CMEM_IOCFREEHEAP CMEM_IOCFREE | CMEM_HEAP 
#define CMEM_IOCFREEPHYS CMEM_IOCFREE | CMEM_PHYS 
#define CMEM_IOCFREEHEAPPHYS CMEM_IOCFREE | CMEM_HEAP | CMEM_PHYS 


从 功能 看 已 经 设计 了 完整 的 内 存 管理 和 cache 管理 功能 。 有 了 该 内 存 管理 功能 ，TI 的 多 
媒体 框架 和 编 解 码 库 就 可 以 使 用 连续 的 物理 内 存 空 间 ， 高 效 地 完成 多 媒体 处 理 相 关 的 功能 。 





4.5 ”直接 存储 器 访问 单元 (DMA) 


从 硬件 的 角度 ，DMA 可 以 说 是 继 中 断 之 后 男 一 个 重要 的 里 程 碑 。 它 开创 了 人 硬件 加 速 的 
时 代 来 解放 处 理 吕 资源 ， 继 DMA 之 后 各 种 特定 功能 的 硬件 加 速 应 运 而 生 , 但 只 有 DMA 有 
如 此 广泛 的 应 用 。 现 如 今 应 用 处 理 需 都 会 集成 DMA， 可 见 DMA 的 重要 性 。 


4.5.1 DMA 使 用 和 管理 基本 需求 


要 了 解 DMA 使 用 和 管理 的 基本 需求 ， 需 要 清楚 DMA 在 系统 框架 中 的 位 置 ， 图 4-43 是 
带 有 DMA 的 系统 框图 。 

在 图 4-43 中 可 见 DMA 是 在 总 线 上 ， 它 可 以 访问 memory 和 外 设 ， 另 外 CPU 可 以 访问 控 
制 DMA ， 外 设 也 可 以 通过 信和 号 来 发 起 DMA 的 操作 ， 只 有 memory 是 纯 的 数据 设备 。DMA 可 
以 读 写 memory 和 外 设 ， 这 样 就 可 以 在 外 设 和 内 存 之 间 传 送 数据 ， 注 意 这 里 有 方向 问题 。 另 
外 也 可 通过 DMA 在 memory 之 间 传 送 数据 ， 这 样 就 有 复制 和 逮 辑 转换 的 功能 。 从 功能 的 角 
BE, 需要 DMA 在 能 力 范围 内 完成 各 种 数据 传输 的 工作 ， 而 对 内 存 的 组 织 尽量 有 更 广泛 的 适 
用 范围 ， 还 需要 保证 数据 传输 的 正确 性 和 一 臻 性， 以 及 与 CPU 访问 的 同步 。 从 管理 的 角度 
考虑 ，DMA 是 一 种 公共 资源 ， 公 共 资 源 的 管理 需要 能 够 随时 请 求 、 释 放 和 设置 ， 并且 需要 
保证 在 使 用 资源 者 之 间 不 发 生 冲 突 。 由 于 DMA 在 使 用 的 时 候 离 不 开 memory 资源 ， 所 以 
DMA 的 使 用 还 要 包括 对 其 使 用 的 内 存 资源 的 管理 。 
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4.5.2 DMA 使 用 和 管理 框架 介绍 


由 于 DMA 和 芯片 体系 相关 ， 各 个 芯片 三 商 的 设计 接口 参数 是 不 同 的 。 由 于 DMA 需要 
访问 内 存 ， 所 以 在 早期 的 Linux 内 核 提 供 的 使 用 和 管理 框架 主要 是 内 存 管理 的 框架 ， 这 些 框 
架 用 于 分 配 和 管理 DMA 要 使 用 的 内 存 资源 ， 规 范 DMA 和 CPU 访问 内 存 区 域 的 流程 。 所 有 
这 些 管理 方式 都 在 dma- mapping. h 中 有 声明 。 这 里 用 mapping 的 概念 表示 内 存 资源 的 管理 也 
是 合适 的 ， 毕 竟 这 些 内 存 无 论 从 CPU 还 是 DMA 访问 都 相当 于 一 个 映射 的 过 程 。 

1. 一 致 性 DMA 映射 管理 

首先 常用 的 是 一 致 性 DMA 映射 ， 这 里 的 一 致 性 主要 是 指 CPU 和 DMA 访问 的 一 致 性 ， 
其 中 相应 的 内 存 区 域 一 般 都 是 关闭 cache 的 ， 这 样 数 据 可 以 保持 一 致 性 。 另 外 相应 的 区 域 
CPU 和 设备 是 可 以 同时 访问 的 ， 这 是 建立 在 一 致 性 基础 上 的 。 对 系统 来 说 ， 该 特性 还 是 比 
较 重 要 的 ， 这 样 减少 了 同步 的 操作 。 

Linux 内 核 提供 了 一 组 DMA 一 致 映射 的 接口 ， 具 体 如 下 : 




















/* x 
* dma_alloc_coherent — allocate consistent memory for DMA 
* @ dev: valid struct device pointer, or NULL for ISA and EISA - like devices 
* @ size; required memory size 


* @ handle; bus - specific DMA address 


* Allocate some uncached, unbuffered memory for a device for 
* performing DMA. This function allocates pages, and will 

* return the CPU - viewed address, and sets (9 handle to be the 
* device — viewed address. 

* / 


extern void * dma_alloc_coherent( struct device * , size t, dma_addr_t * , efp t) ; 
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fi eR 


* dma free coherent — free memory allocated by dma_alloc_coherent 


* (Q dev: valid struct device pointer, or NULL for ISA and EISA - like devices 


* @ size; size of memory originally requested in dma, alloc. coherent 


* @cpu addr: CPU - view address returned from dma, alloc, coherent 


* (handle: device — view address returned from dma. alloc. coherent 


* Free( and unmap)a DMA buffer previously allocated by 


* dma, alloc, coherent( ). 


* References to memory and mappings associated with cpu, addr/handle 


* during and after this call executing are illegal. 


*/ 


extern void dma, free coherent( struct device * , size t, void * , dma, addr t) ; 


fe ds 


* dma mmap. coherent — map a coherent DMA allocation into user space 
* @ dev: valid struct device pointer, or NULL for ISA and EISA - like devices 


* (90 vma; vm area, struct describing requested user mapping 


* @cpu_addr; kernel CPU — view address returned from dma  alloc, coherent 


* (handle: device — view address returned from dma. alloc. coherent 


* @ size; size of memory originally requested in dma_alloc_coherent 


* Map a coherent DMA buffer previously allocated by dma. alloc, coherent 


* into user space. The coherent DMA buffer must not be freed by the 


* driver until the user space mapping has been released. 
*/ 
int dma_mmap_coherent(struct device * , struct vm. area struct * , 


void * , dma, addr t, size t) ; 





这 里 保留 相应 的 注释 ， 主 要 是 相应 的 注释 都 很 明确 地 表述 了 相应 接口 的 功能 。 对 这 些 接 
s 间 ， 在 驱动 退出 时 释放 
的 空间 。 如 果 驱 动 支持 在 相应 空间 被 应 用 程序 访问 ， 则 通过 dma_mmap_coherent 来 进行 

需要 注意 的 是 ， 特 殊 的 设备 在 映射 时 ， 相 同 的 物理 内 存 空间 对 于 CPU 和 DMA 是 不 同 


使 用 ， 通 常 是 在 要 使 用 DMA 的 设备 驱动 初始 化 时 分 配 相应 的 空 












































址 ， 相 应 的 分 配 接口 是 通过 传 址 参数 来 返回 DMA 视角 的 地 址 ， 





地 址 ， 这 样 在 系统 级 别 达到 一 致 性 。 





通过 返回 值 返 回 CPU 视 


一 致 性 映射 的 空间 在 整个 驱动 的 生命 周期 中 都 被 使 用 ， 可 以 说 是 驱动 的 一 个 组 成 部 分 ， 











是 可 以 对 应 用 层 开 放 并 提供 映射 接口 的 。 
一 致 性 接口 的 粒度 比较 大 ， 是 以 页 为 单位 的 ， 并 且 不 能 提供 








参考 kmem_cache 的 方式 ，DMA 也 可 以 将 所 有 的 一 定 大 小 的 空 


Eat hy) DMA 传输 需要 的 





间 需 求 组 织 在 一 起 ， 


进行 





整体 的 物理 内 存 分 配 ， 而 该 大 小 的 单个 DMA 分 配 需求 ， 作 为 细 粒 度 的 DMA 操作 ， 通 过 相 
应 的 接口 在 整体 申请 的 DMA 空间 中 进行 分 配 和 操作 。 这 样 就 形成 一 个 池 的 功能 ， 而 相应 的 
接口 就 是 dma_pool。 详 细 的 说 明 如 下 : 


人 /沙洲 
* dma_pool_create — Creates a pool of consistent memory blocks, for dma. 
* @name; name of pool, for diagnostics 
* @dev; device that will be doing the DMA 
* @ size; size of the blocks in this pool. 
* Q align: alignment requirement for blocks; must be a power of two 
* @ boundary; returned blocks won t cross this power of two boundary 


* Context; !in_interrupt( ) 


* Returns a dma allocation pool with the requested characteristics, or 
* null if one can t be created. Given one of these pools, dma, pool, alloc( ) 


" consistent" 


* may be used to allocate memory. Such memory will all have 
* DMA mappings, accessible by the device and its driver without using 
* cache flushing primitives. The actual size of blocks allocated may be 


* larger than requested because of alignment. 


* If € boundary is nonzero, objects returned from dma, pool. alloc( ) won t 
* cross that size boundary. — This is useful for devices which have 
* addressing restrictions on individual DMA transfers, such as not crossing 
* boundaries of 4KBytes. 
*/ 

struct dma, pool * dma, pool create( const char * name, struct device * dev, 


size t size, size t align, size t boundary ) 


/* x 
* dma_pool_alloc — get a block of consistent memory 
* @ pool; dma pool that will produce the block 
* @ mem flags: GFP. * bitmask 
* @ handle; pointer to dma address of block 


* This returns the kernel virtual address of a currently unused block, 
* and reports its dma address through the handle. 
* |f such a memory block car t be allocated, 96 NULL is returned. 
*/ 

void * dma, pool, alloc( struct dma, pool * pool, gfp t mem flags, 


dma, addr t * handle) 


Js & 


* dma pool free — put block back into dma pool 
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* 


@ pool; the dma pool holding the block 
@ vaddr; virtual address of block 
@ dma; dma address of block 


Caller promises neither device nor driver will again touch this block 


unless it is first re — allocated. 


*/ 


void dma, pool free( struct dma, pool * pool, void * vaddr, dma, addr t dma) 


jo & 


* 


* 


* 


* 


dma_pool_destroy — destroys a pool of dma memory blocks. 


@ pool; dma pool that will be destroyed 


Context; !in_interrupt( ) 


Caller guarantees that no more memory from the pool is in use, 


and that nothing will try to use the pool after this call. 
* / 


void dma_pool_destroy( struct dma_pool * pool) 


整体 的 dma pool 创建 和 销毁 可 使 用 dma_pool_create 和 dma_pool_destroy， 而 细 粒 度 的 分 
配 和 释放 可 使 用 dma_pool_alloc 和 dma_pool_free。 

2. 流 式 DMA 映射 管理 

一 致 性 映射 是 消耗 比较 大 的 映射 ， 主 要 是 一 旦 分 配 后 只 能 在 驱动 退出 时 才能 释放 ， 这 样 
相当 于 驱动 一 直 占 用 内 存 资 源 ， 而 并 不 管 是 否 要 进行 DMA 相关 的 操作 。 由 于 驱动 并 不 是 一 








解决 该 问题， 





Linux 内 核 提 伐 











直 都 需要 使 用 相应 的 内 存 资源 进行 DMA 操作 ， 这 在 一 定 程度 上 造成 了 比较 大 的 开销 。 为 了 
t 了 流 式 DMA 映射 方式 ， 相 应 的 内 存 只 有 在 需要 进行 DMA 操作 





之 前 才 进 行 DMA 相关 的 映射 ， DMA 操作 完 之 后 进行 映射 的 释放 ， 这 样 在 进行 DMA 操作 之 
外 的 时 间 由 CPU 进行 处 理 。 这 样 保证 相应 的 空间 ， 只 在 DMA 操作 期 间 才 归 驱 动 的 DMA 操 
作 所 有 ， 之 外 CPU 可 以 进行 任何 处 理 ， 释 放 修 改 等 都 可 以 ， 比 较 适合 用 户 空 间 通 过 驱动 传 
输 数 据 的 操作 。 相 应 的 接口 细节 如 下 : 


Jf te & 


* 


* 
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dma, map. single — map a single buffer for streaming DMA 


@ dev: valid struct 


device pointer, or NULL for ISA and EISA - like devices 


@ cpu, addr: CPU direct mapped address of buffer 


@ size; size of buffer to map 
€ dir; DMA transfer direction 


Ensure that any data held in the cache is appropriately discarded 


or written back. 


* 


* 


* 


The device owns this memory once this call has completed. The CPU 
can regain ownership by calling dma_unmap_single( ) or 


dma, sync, single for cpu( ). 


*/ 


static inline dma_addr_t dma, map. single(struct device * dev, void * cpu, addr, 


size t size, enum dma, data, direction dir) 


fi & & 


* 


* 


dma, map. page — map a portion of a page for streaming DMA 

@ dev: valid struct device pointer, or NULL for ISA and EISA - like devices 
(? page: page that buffer resides in 

@ offset: offset into page for start of buffer 

@ size; size of buffer to map 


€ dir; DMA transfer direction 


Ensure that any data held in the cache is appropriately discarded 


or written back. 


The device owns this memory once this call has completed. The CPU 


can regain ownership by calling dma_unmap_page( ). 


*/ 


static inline dma, addr t dma, map. page( struct device * dev, struct page * page, 


unsigned long offset, size t size, enum dma, data, direction dir) 


"2 & 


* 


* 


dma, unmap. single — unmap a single buffer previously mapped 

@ dev: valid struct device pointer, or NULL for ISA and EISA - like devices 
€ handle; DMA address of buffer 

@ size; size of buffer( same as passed to dma map. single) 


@ dir; DMA transfer direction( same as passed to dma, map. single) 


Unmap a single streaming mode DMA translation. The handle and size 
must match what was provided in the previous dma, map. single( ) call. 


All other usages are undefined. 


After this call, reads by the CPU to the buffer are guaranteed to see 


whatever the device wrote there. 


*/ 


static inline void dma, unmap. single( struct device * dev, dma, addr t handle, 


size t size, enum dma, data, direction dir) 
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* 


* 


dma, unmap. page — unmap a buffer previously mapped through dma, map. page( ) 
@ dev: valid struct device pointer, or NULL for ISA and EISA - like devices 

@ handle; DMA address of buffer 

@ size; size of buffer(same as passed to dma map. page) 


@ dir; DMA transfer direction( same as passed to dma, map. page) 


Unmap a page streaming mode DMA translation. The handle and size 
must match what was provided in the previous dma, map. page( ) call. 


All other usages are undefined. 


After this call, reads by the CPU to the buffer are guaranteed to see 


whatever the device wrote there. 


*/ 


static inline void dma, unmap. page( struct device * dev, dma, addr t handle, 


size t size, enum dma, data, direction dir) 


可 见 这 些 接口 有 一 段 数据 的 映射 也 有 物理 页 的 映射 ， 这 里 接口 并 不 负责 分 配 空间 ， 而 是 


ES 





解决 内 存 所 有 者 的 问题 ， 并 附加 进行 方向 的 检查 ， 保 证 数据 的 一 致 性 以 及 和 CPU 的 同步 。 





3. 散 列 式 DMA 映射 管理 


流 式 DMA 映射 处 理 器 和 DMA 


次 只 能 交互 单 次 的 DMA 传输 数据 ， 相 对 来 说 效率 低 一 








= 
些 。 在 内 核 中 很 多 模块 及 层次 都 是 需要 批量 处 理 数 据 的 能 力 ， 这 就 要 求 进行 DMA 相关 映射 


管理 的 时 候 ， 
量 数据 后 再 由 DMA 进行 循环 操作 完成 批量 传输 。 相 关 的 接口 细节 如 下 : 

















要 能 进行 数据 批量 的 交互 ， 批 量 交 给 驱动 进行 DMA 传输 工作 ， 驱 动 接收 到 批 














JE ds 


* 


dma, map. sg — map a set of SG buffers for streaming mode DMA 

@ dev: valid struct device pointer, or NULL for ISA and EISA - like devices 
@ sg: list of buffers 

@ nents: number of buffers to map 

@ dir; DMA transfer direction 


Map a set of buffers described by scatterlist in streaming mode for DMA. 


This is the scatter — gather version of the dma, map. single interface. 


* Here the scatter gather list elements are each tagged with the 

* appropriate dma address and length. They are obtained via 

* sg dma, | address, length}. 

* 

* Device ownership issues as mentioned for dma map. single are the same 
* here. 

*/ 


int dma, map. sg(struct device * dev, struct scatterlist * sg, int nents, 
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enum dma, data, direction dir) 


/* x 
* dma unmap. sg — unmap a set of SG buffers mapped by dma_map_sg 
* @ dev: valid struct device pointer, or NULL for ISA and EISA - like devices 
* @ sg: list of buffers 
* @ nents; number of buffers to unmap( returned from dma, map. sg) 


* (dir; DMA transfer direction( same as was passed to dma, map. sg) 


* Unmap a set of streaming mode DMA translations. Again, CPU access 
* rules concerning calls here are the same as for dma_unmap_single( ). 
*/ 

void dma, unmap. sg( struct device * dev, struct scatterlist * sg, int nents, 


enum dma, data, direction dir) 


相应 的 批量 映射 的 区 域 由 参数 sg 表示 ， 在 进行 DMA 操作 之 前 ， 将 dma map. sg 映射 给 
驱动 ， 驱 动 批量 DMA 操作 结束 后 ， 调 用 dma_unmap_sg， 将 相关 区 域 归还 ， 上 层 框 架 会 继续 
处理 相关 区 域 。 

4. 体系 结构 相关 接口 

在 体系 结构 中 ,具体 的 设备 允许 通过 DMA 访问 的 地 址 空间 可 能 是 受 限 的 ， 这 就 需要 对 
相应 的 设备 进行 标注 ， 从 而 在 上 面 的 映射 接口 中 进行 正确 的 操作 。 相 应 的 限制 会 和 设备 绑 
定 ， 因 为 DMA 的 最 终 使 用 者 会 以 物理 设备 和 逻辑 设备 的 形式 存在 ， 这 样 的 限制 和 设备 绑 定 
更 合理 。 相 应 的 详细 接口 如 下 : 






































/ * 
* Return whether the given device DMA address mask can be supported 
* properly For example, if your device can only drive the low 24 — bits 
* during bus mastering, then you would pass OxOOffffff as the mask 


* to this function. 


* FIXME; This should really be a platform specific issue — we should 
* return false if GFP_DMA allocations may not satisfy the supplied mask . 
*/ 


static inline int dma, supported( struct device * dev, u64 mask) 


static inline int dma, set, mask( struct device * dev, u64 dma, mask) 


5. DMA engine 框架 
以 上 都 是 和 DMA 操作 的 内 存 管理 相关 的 框架 和 接口 ， 并 没有 涉及 DMA 操作 的 统一 接 
口 和 DMA 自身 资源 管理 部 分 。 有 统一 的 接口 可 以 使 得 驱动 的 抽象 程度 更 高 ， 减 少 不 同 芯片 
相同 功能 驱动 的 差异 ， 提 高 可 移植 性 ， 可 以 提供 统一 的 IP 级 别 的 驱动 。 但 是 这 在 早期 的 
Linux 内 核 中 都 没有 提供 ， 新 的 Linux 内 核 才 通过 DMA engine 框架 提供 了 该 部 分 功能 。DMA 
engine 是 上 层 框架 ， 主 要 是 对 DMA 的 操作 和 属性 进行 管理 和 抽象 ， 其 中 将 DMA 作为 设备 来 
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管理 。 要 实现 完整 的 功能 还 需要 各 种 芯片 的 支持 以 及 各 种 设备 驱动 的 移植 。 由 于 是 新 内 核 才 
提供 的 功能 ， 并 不 是 所 有 的 芯片 都 文 持 该 功能 ， 所 以 下 面 只 是 对 接口 进行 简单 的 说 明 。 
分 配 DMA 内 部 channel 的 接口 ， 

















struct dma_chan * dma_request_channel( dma_cap_mask_t mask, 
dma, filter fn filter fn, 


void * filter param) ; 





DMA 特殊 属性 配置 的 接口 : 


int dmaengine_slave_config( struct dma_chan * chan, 


struct dma_slave_config * config) 


DMA 传输 的 描述 结构 是 struct dma_async_tx_descriptor。 
设备 中 会 有 如 下 的 接口 来 绑 定 物理 内 存 和 设备 的 DMA 操作 ， 并 返回 抽象 的 DMA 传输 
描述 结构 : 








struct dma_async_tx_descriptor * ( * chan —> device —» device. prep. slave, sg) ( 
struct dma, chan * chan, struct scatterlist * sgl, 
unsigned int sg len, enum dma_data_direction direction, 
unsigned long flags) ; 

struct dma, asyne, tx descriptor * ( * chan -> device -> device prep. dma, cyclic) ( 
struct dma, chan * chan, dma, addr t buf addr, size t buf len, 
size t period len, enum dma, data. direction direction) ; 

struct dma, asyne, tx. descriptor * ( * device, prep. interleaved, dma) ( 
struct dma, chan * chan, struct dma_interleaved_template * xt, 


unsigned long flags) ; 
发 起 传输 的 接口 : 
dma_cookie_t dmaengine_submit( struct dma_async_tx_descriptor * desc ) 
另外 还 有 DMA 传输 的 控制 接口 : 


int dmaengine_terminate_all(struct dma_chan * chan) 

int dmaengine pause( struct dma_chan * chan) 

int dmaengine, resume( struct dma chan * chan) 

enum dma, status dma, async, is tx complete( struct dma chan * chan, 


dma, cookie t cookie, dma, cookie t * last, dma, cookie t * used) 





以 上 接口 可 以 说 已 经 抽象 出 各 种 DMA 操作 及 控制 ， 是 很 好 的 上 层 框架 。 
4.5.3 TI 芯片 DMA 使 用 和 管理 相关 实现 详解 


要 了 人 解 具 体 蕊 片 的 DMA 使 用 和 管理 ， 首 先 要 看 一 下 硬件 的 设计 。DM 3730 芯片 内 部 的 
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DMA 是 System DMA (SDMA), SDMA 和 其 他 模块 联系 的 系统 框图 如 图 4-44 所 示 。 图 4-44 
引 自 《DM 3730 芯片 手册 》 中 第 2339 页 的 框图 。 
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图 4-44 DM 3730 SDMA 与 其 他 模块 联系 系统 框图 


从 图 4-44 可 见 ，SDMA 共有 96 个 DMA 请 求 ， 用 于 设备 请 求 DMA 进行 数据 传输 处 理 。 
SDMA 可 以 访问 到 外 设 并 可 以 响应 芯片 外 部 的 DMA 请求。 为 了 提高 整个 的 DMA PERE, DMA 
提供 多 个 中 断 信 号 给 处 理 器 ,来 加 速 系统 对 DMA 处 理 数据 过 程 的 响应 。 需 要 注意 的 是 DM 
3730 中 有 两 个 主要 的 处 理 器 : 一 个 是 ARM MPU ， 另 一 个 是 IVA (实际 是 DSP)。 两 个 主 核 
都 有 对 DMA 的 需求 ， 所 以 在 DMA 处 理 部 分 也 要 考虑 多 核 相关 的 支持 ， 保 证 多 核 间 不 会 对 
DMA 内 部 资源 访问 造成 冲突 。 

SDMA 系统 内 部 的 框架 如 图 4-45 所 示 。 图 4-45 314 (DM 3730 芯片 手册 》 中 第 2344 
页 框图 。 

从 图 4-45 可 见 ，SDMA 只 有 一 个 用 于 读 操作 和 一 个 用 于 写 操作 的 端口 ，SDMA 内 部 通 
过 logical channel 管理 不 同 的 传输 请 求 ， 通 过 调度 器 以 及 优先 级 来 进行 调度 ， 男 外 通过 FIFO 
来 缓冲 每 个 逻辑 channel 的 数据 。SDMA 有 32 个 逻辑 channel， 每 个 channel 均 可 单独 设置 ， 
并 且 可 以 将 多 个 channel 串 成 逻辑 链 。 

接 下 来 分 几 部 分 进行 详细 的 解析 。 

1. 逻辑 channel 的 管理 

对 于 逻辑 channel 的 管理 主要 是 请 求 和 释放 。 
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// 其 他 模块 请 求 DMA 的 接口 函数 ,要 设置 DMA channel 是 哪个 设备 使 用 


int omap. request. dma( int dev. id, const char * dev name, 





void( * callback) (int Ich, ul6 ch, status, void * data), 


void * data, int * dma, ch, out) 


int ch, free_ch = -1; 
unsigned long flags; 


struct omap. dma lch * chan; 


MA 中断 加 锁 保 护 channel 管理 的 结构 
spin_lock_irqsave( &dma_chan_lock, flags) ; 


// 查 找 没有 使 用 的 channel 对 应 的 管理 结构 
for( ch 20; ch < dma chan count; ch ++ ) | 
if( free ch == -1 && dma_chan| ch]. dev id == -1)| 
free ch = ch; 
if( dev. id 220) 
break ; 








| 

if( free ch == -1)| 
spin, unlock, irqrestore( &dma, chan. lock, flags) ; 
return — EBUSY; 


// 找 到 相应 的 管理 结构 
// 设 置 相应 的 device. id 
chan = dma_chan + free_ch; 


chan -> dev_id = dev_id; 


// 如 果 有 channel 清除 寄存 器 操作 则 清除 ,omap3 中 没有 该 操作 
if( p —>clear_lch_regs) 





p —> clear lch. regs( free ch) ; 


// omap3 有 单独 的 clear 操作 ,omap3 中 channel 相关 的 寄存 器 写 0 
/7 清除 状态 csr 以 便 可 以 start_dma 
if(cpu_class_is_omap2( )) 


omap. clear. dma( free ch) ; 


// 可 以 释放 锁 


spin_unlock_irqrestore( &dma_chan_lock, flags); 





// 设 置 其 他 属性 
chan -> dev. name = dev. name; 
//callback 及 data Jy DMA 操作 中 断 ing 处 理 函 数 的 回调 及 所 用 参数 


chan —> callback = callback ; 








chan —> data = data; 


chan —> flags 20; 


#ifndef CONFIG. ARCH, OMAPI 
if( cpu, class is omap2( ) ) | 
// 目 前 没有 在 chain 中 也 没有 next_link ,相应 的 域 要 初始 化 


chan —>chain_id = -1; 





chan —» next, linked ch = -1; 


| 
#endif 


// 记 录 要 使 能 的 中 断 包括 dma_drop( 丢失 DMA 中 断 ) 
// fll block, irq( block 传输 完毕 中 断 ) 
chan —> enabled_irqgs = OMAP_DMA_DROP_IRQ | OMAP_DMA_BLOCK_IRQ; 
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//omap3 还 要 使 能 MISALIGNED_ERR_IRQ( 地 址 没有 对 齐 错 误 中 断 ) 
// Wl TRANS ERR. IRQ( 传输 错误 中 断 ) 以 便 检查 传输 错误 
if(cpu_class_is_omapl( )) 
chan —> enabled_irqs 2 OMAP1_DMA_TOUT_IRQ; 
else if( cpu. class is omap2( ) ) 
chan —> enabled, irqs E OMAP2 DMA MISALIGNED ERR, IRQ | OMAP2_DMA_TRANS_ 
ERR_IRQ; 


if( epu. elass is omap2( ) ) | 
//enable channel 对 MPU É% HP Wr 
omap2. enable, irq. lch( free ch) ; 
// enable 相应 的 channel 的 中 断 , 写 channel 的 cier AIFA 


omap_enable_channel_irq(free_ch ) ; 








/ * Clear the CSR register and IRQ status register * / 

// 38 É& channel AY csr 中 断 寄存 带 

p -> dma write( OMAP2_DMA_CSR_CLEAR_MASK, CSR, free ch) ; 
// 清 除 channel 对 MPU 的 irqstatus 相应 位 ,以 便 中 断 可 用 

p ->dma_write(1 << free ch, IRQSTATUS_LO, 0); 








// 返 回 相应 的 channel 号 


* dma_ch_out = free_ch; 


return 0; 


// 释 放 相 应 的 DMA channel 
void omap_free_dma( int Ich) 
| 


unsigned long flags; 


if( dma, chan[ lch]. dev id == -1)| 
pr. err( " omap. dma; trying to free unallocated DMA channel 96 d\n" ,lch) ; 


return ; 


if( epu. elass is omap2( ) ) | 
// Ti 253. disable 相应 的 channel 对 MPU 的 中 断 
omap2, disable irq lch(lch) ; 





/ * Clear the CSR register and IRQ status register * / 
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// 清 除 channel 中 断 状 态 寄 存 器 

p -> dma_write( OMAP2_DMA_CSR_CLEAR_MASK, CSR, lch); 
// 清 除 channel 对 MPU 的 irq status 

p ->dma_write(1 < lch, IRQSTATUS IO, lch); 








/ * Disable all DMA interrupts for the channel. */ 
// disable channel "rj cicr 为 0 , 关 掉 所 有 中 断 
p —>dma_write(0, CICR, lch); 


/ * Make sure the DMA transfer is stopped. * / 
//*3 channel control register 为 0 , 停 掉 DMA 

p —>dma_write(0, CCR, lch); 

// 清 除 channel 的 寄存 器 


omap. clear. dma( lch) ; 








// 清 除 其 channel 管理 实体 相应 的 属性 ,以 便 可 以 再 请 求 
spin, lock, irqsave( &dma, chan lock, flags) ; 

dma, chan[ lch]. dev id = -1; 

dma, chan[ Ich |. next lch = -1; 

dma, chan[ Ich ]. callback = NULL; 


spin, unlock, irqrestore( &dma, chan, lock, flags) ; 


可 








2. 逻辑 channe 的 参数 设置 接口 

逻辑 channel 的 各 种 设置 包括 很 多 的 寄存 器 操作 ， 会 涉及 芯片 手册 的 一 些 细节 ， 对 细节 
中 设计 芯片 手册 的 内 容 ， 直 接 在 注释 中 以 英文 的 形式 存在 。 相 应 的 接口 主要 是 对 申请 到 的 逻 
辑 channel 进行 设置 ; 














// 设 置 channel 的 优先 级 ,对 于 omap3 sdma 只 有 high/low 两 个 优先 级 ,主要 差别 是 分 
// 得 fifo 不 同 。omap3 上 设置 ccr 的 read 优先 级 实现 
void omap_set_dma_priority(int Ich, int dst, port, int priority ) 


| 























unsigned long reg; 


u32 1; 


//omap3 上 主要 是 设置 cer 的 read 优先 级 
if(cpu_class_is_omap2( ) | 


u32 ccr; 


cer = p - » dma, read( CCR, Ich) ; 
if( priority ) 
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ccr |= (1<«<6); 
else 
ccr & = ~(1 «K6); 
p -> dma_write( ccr, CCR, lch); 








// 设 置 channel 的 transfer 属性 ,主要 是 cor 的 设置 


void omap_set_dma_transfer_params( int lch, int data_type, int elem_count, 






































int frame_count, int sync_mode, 


int dma_trigger, int src_or_dst_synch) 


u32 l; 


// 设 置 data_type 是 在 cdsp 低 2bits 

//#define OMAP_DMA_DATA_TYPE_S8 0x00 
//#define OMAP_DMA_DATA_TYPE_S16 0x01 
//#define OMAP DMA, DATA TYPE S32 0x02 
l = p-»dma read( CSDP, lch); 

1 &= ~0x03; 











l |= data_type; 
p -» dma write(1, CSDP, lch); 


if( cpu, class is omap2( ) && dma trigger) | 
u32 val; 


val = p -> dma, read( CCR, lch); 


/* DMA, SYNCHRO CONTROL UPPER depends on the channel number * / 

// 默 认 关 掉 prefetch 等 ,关联 的 硬件 dma, request 信号 由 dma, trigger 表示 ,通常 为 0 ~ 
//4bit,5 个 bit 表示 低 5bits, 男 外 19 ~ 20 bit 表示 高 2bits。 如 果 是 software synchronization 
//trigger 的 DMA 操作 ,dma_trigger 应 该 设置 为 0 

val & = ~((1<23) | (3 «19) |0x1f); 

val |= (dma_trigger & ~ Oxlf) << 14; 





























val |= dma_trigger & Ox1f; 


// Frame synchronization 

// This bit used with the BS to see how the DMA request is serviced in a synchronized transfer 
// FS x0 and BS =0; An element is transferred once a DMA request is made. 

// FS x0 and BS =1; An entire block is transferred once a DMA request is made. 

// FS x1 and BS 20; An entire frame is transferred once a DMA request is made. 

// FS Z1 and BS =1; A packet is transferred once a DMA request is made. 


// All these different transfers can be interleaved on the port with other DMA requests. 
// 注 意 packet 同步 模式 要 求人 =1 并 且 bs =1, 所 以 宏 定义 中 
// sync_packet 为 3 包括 了 sync, frame 和 sync, block 
if( sync_mode & OMAP_DMA_SYNC_FRAME) 
val E 1««5; 





else 


val & = ~(1 <5); 


if(sync_mode & OMAP_DMA_SYNC_BLOCK) 
val |=1 «18; 
else 


val & = ~(1 <«<18); 


//Prefetch mode is active only when destination is synchronized 
// 设 置 源 还 是 目的 dma_request 来 触发 dma channel 的 传输 
if( src, or. dst, synch == OMAP_DMA_DST_SYNC_PREFETCH) | 
val & = ~ (1 ««24) ;/ * dest synch */ 
val |2 (1««23) ;/ * Prefetch * / 








} else if( src, or. dst, synch) | 
val |=1 <<24;/ * source synch * / 
| else | 
val & = ~ (1 ««24) ;/ * dest synch */ 
| 
p —>dma_write( val, CCR, lch); 


// 设 置 传输 的 count ,包括 一 帧 的 element 数 和 一 个 block 的 frame 数 
p —> dma_write( elem_count, CEN, lch); 
p —> dma_write( frame count, CFN, Ich) ; 


| 


// X] source 和 destination 的 参数 设置 物理 上 有 寄存 器 csdp 即 channel source destination parameter 
// ER 
// 设 置 source 的 参数 ,omap3 中 没有 sre; port 参数 


























//sre_amode 的 设置 在 cer 寄存 器 中 
//Selects the addressing mode on the Read Port of a channel. 设置 的 原理 见 tm 11. 4. 3 
// 0x0: Constant address mode Oxl: Post — incremented address mode 
// 0x2; Single index address mode — 0x3; Double index address mode 
// 这 里 设置 source 的 参数 主要 是 地 址 自动 操作 的 模式 及 element index 和 frame index 
void omap_set_dma_src_params( int Ich, int src. port, int src_amode， 

unsigned long src, start , 


int sre, ei, int sro, fi) 
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u32 |; 


// 设 置 amode ,自动 地 址 的 操作 模式 
]2p-»dma read( CCR, lch); 

l & = ~ (0x03 «12); 

l |= src_amode << 12; 

p —>dma_write(1, CCR, lch); 


// 设 置 source 的 物理 地 址 
p -> dma, write( sre, start, CSSA, lch); 


// 设 置 element index 和 frame index 
p-> dma, write( sre, ei, CSEI, lch); 
p -> dma  write( sre, fi, CSFI, lch); 
| 
EXPORT_SYMBOL( omap. set. dma. sre. params ) ; 




















// 设 置 DMA 的 参数 ,对 相应 的 驱动 一 次 配置 好 所 有 channel 的 参数 后 使 用 
void omap_set_dma_params(int Ich, struct omap_dma_channel_params * params) 


| 


























// 设 置 传输 参数 
omap_set_dma_transfer_params( lch, params —> data, type, 
params —>elem_count, params — > frame, count, 
params —> sync mode, params —> trigger, 
params -> src, or, dst. synch) ; 
// 设 置 source 的 参数 
omap_set_dma _sre_params(Ich, params 一 > src. port, 
params 一 > src_amode , params 一 > src, start, 
params —>sre_ei, params —> src, fi) ; 
/ / A EE target 的 参数 
omap. set, dma, dest, params(lch, params -> dst, port , 
params —> dst amode, params —> dst, start, 
params —> dst. ei, params —> dst. fi) ; 
// 设 置 read/write 优先 级 
if( params -> read_prio || params -> write, prio) 
omap. dma, set, prio. lch(lch, params —» read, prio, params —> write, prio) ; 
| 
EXPORT_SYMBOL( omap_set_dma_params ) ; 








// 设 置 是 否 enable DMA 的 source 为 package 操作 方式 ;package 方式 可 以 将 
//element 组 成 package 以 满足 DMA read/write port 的 size. 不 支持 constant 地 址 方式 

















void omap_set_dma_srce_data_pack( int Ich, int enable) 


| 


| 





u32 |; 


l = p -> dma read( CSDP, lch); 
l&=-~(1<«6); 
// 如 果 enable 设置 source 为 pack enable 
if( enable) 

1 |=(1 <«6); 
p -> dma write(1, CSDP, lch); 





EXPORT_SYMBOL( omap. set. dma, src, data, pack ) ; 





// dest, amode 的 设置 在 cer 寄存 器 中 


//Selects the addressing mode on the Read Port of a channel. 设置 的 原理 见 tm 11. 4. 3 


// 0x0; Constant address mode 0xl : Post — incremented address mode 


// 0x2; Single index address mode — 0x3; Double index address mode 


// 这 里 设置 destination 的 参数 主要 是 地 址 自动 操作 的 模式 及 element index 和 frame index 


void omap. set. dma, dest, params( int Ich, int dest. port, int dest_amode, 


| 


unsigned long dest, start, 


int dst, ei, int dst, fi) 
u32 1; 


/人 /设置 地 址 操作 模式 

] 2p-»dma read( CCR, lch); 
l & = ~ (0x03 «14) ; 

l = dest_amode << 14; 

p -»dma write(1, CCR, lch); 


/ / 4, destination start 物理 地 址 
p —> dma, write( dest, start, CDSA, Ich) ; 


// 设 置 element index 和 frame index 
p -» dma, write( dst, ei, CDEI, Ich) ; 
p -> dma, write( dst, fi, CDFI, Ich) ; 


EXPORT_SYMBOL( omap. set. dma. dest. params) ; 


dg 


// element 组 成 package 以 满足 DMA read/write port 的 size. 不 支持 constant 地 址 方式 


设 








置 是 否 enable DMA 的 destination 为 package 操作 方式 ;package 方式 可 以 将 

















void omap_set_dma_dest_data_pack( int Ich, int enable) 
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u32 |; 


]2p-»dma read( CSDP, lch); 
1&=~(1<«l3); 
// XI pack 模式 进行 设置 
if( enable) 
1 |=1<«13; 
p -> dma write(1, CSDP, lch); 
| 
EXPORT_SYMBOL( omap. set. dma, dest, data, pack) ; 

















a 





//enable 相应 的 channel 的 irq PAT, AIRES TE start_dma 时 进行 调 
static inline void omap. enable, channel. irq( int Ich) 


| 


u32 status; 


/* Clear CSR */ 
// 首 先 清除 channel status register 


if( cpu_class_is_omapl( ) ) 





status = p -> dma_read( CSR, Ich) ; 
else if( cpu, class is omap2( ) ) 


p -> dma, write( OMAP2 DMA, CSR, CLEAR, MASK, CSR, Ich) ; 





/ * Enable some nice interrupts. * / 

//enable 相应 的 channle "A Wr, channel 的 中 断 记 录 在 channel 的 
// 管 理 逻 辑 结构 中 dma_chan[ lch]. enabled_irqs 

p —> dma_write( dma, chan[ Ich ]. enabled irqs, CICR, Ich) ; 


// disable 相应 的 channel 中 断 
static void omap_disable_channel_irq( int Ich) 
| 
// 写 0 为 disable 所 有 channel 的 中 断 
if( cpu_class_is_omap2( ) ) 
p —>dma_write(0, CICR, lch); 


// 设 置 channel 想 要 enable 的 中 断 , 这 里 只 是 设置 channel 中 eanble_irq 的 
// 有 具体 的 eanble 相应 的 中 断 会 根据 该 属性 进行 cicr 的 配置 


void omap. enable dma_irq(int Ich, u16 bits) 


























可 





l 
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m 


FH 








il 


dma, chan[ Ich |. enabled_irqs |= bits; 


j 
EXPORT_SYMBOL( omap. enable, dma, irq) ; 


























// 设 置 channel 想 要 disable 的 中 断 , 这 里 只 是 设置 channel 中 eanble_irg 的 
// 应 的 中 断 会 根据 该 属性 进行 cicr 的 配置 
void omap_disable_dma_irq( int Ich, u16 bits) 


| 


性 ,具体 的 disable TH 











E 




















可 





dma_chan[ Ich |. enabled_irqs & = ~ bits; 
} 
EXPORT_SYMBOL( omap_disable_dma_irq) ; 
3. 逻辑 channel 的 操作 接口 
逻辑 channel 的 操作 接口 主要 是 启动 、 停 止 以 及 中 断 响应 接口 。 详 细 的 解析 如 下 : 





a 


//omap 上 start DMA 的 操作 接 
void omap_start_dma(int Ich) 
| 

u32 1; 


/* 
* The CPC/CDAC register needs to be initialized to zero 
* before starting dma transfer. 
*/ 
//DMA start 之 前 destination 地 址 计数 寄存 器 需要 清 0 
if( cpu. is. omapl5xx( ) ) 
p -»dma write(0, CPC, lch); 
else 


p -»dma write(0, CDAC, Ich) ; 


if( !omap_dma_in_1510_mode( ) && dma, chan| Ich]. next lch ! = -1)| 
// 这 里 说 明 有 link AY channel, ,需要 设置 link 将 
//channel 串 起 来 


int next_lch, cur_lch; 


pu 





char dma, chan, link map| dma lch, count | ; 





// X chain 使 用 的 channel 进行 标记 

dma_chan link _ mapl lch] =1; 

/ * Set the link register of the first channel */ 

// 设 置 当 前 channel 的 next link ,具体 的 next link TE dma, chan[ Ich]. next, Ich 中 
enable lnk(lch) ; 























// &'& channel 标记 
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memset( dma, chan, link map, 0, sizeof( dma chan link map)); 
/下面 是 遍历 link ,对 link 中 每 个 channel 进行 设置 
cur_lch = dma_chan| Ich |. next_Ich; 

do | 


next_lch = dma_chan{ cur. lch ]. next_Ich; 


























/ * The loop case; we ve been here already * / 
// 如 果 channel 已 经 设置 , 则 说 明 是 循环 link ,退出 
if( dma_chan_link_mapl cur. Ich ] ) 

break ; 
/ * Mark the current channel * / 
/进行 标记 


dma_chan_link_map[ cur_Ich] =1; 








// 设 置 link 
enable, Ink( cur. lch) ; 
// enable channel "PAY HP Wf 


omap. enable channel, irq( cur lch) ; 





// 遍 历 下 一 个 
cur_lch = next_lch ; 
| while(next_Ich ! = -1); 
} else if(IS DMA ERRATA(DMA, ERRATA PARALLEL CHANNELS) ) 
p -> dma write(lch, CLNK CTRL, Ich) ; 





// 使 能 channel 相应 的 irq 


omap. enable channel irq(lch) ; 


// 设 置 channel cer 寄存 器 来 enable 该 channel 

// X software trigger 的 DMA channel ,设置 ccr 寄存 器 的 enable bit 

// 就 直接 触发 DMA 操作 。 如 果 是 hardware trigger 的 channel 会 等 待 相应 的 
//dma_req 信号 触发 

l=p -> dma_read( CCR, lch); 





























if(IS_DMA_ERRATA( DMA_ ERRATA IFRAME_ BUFFERING)) 
| |=OMAP_DMA_CCR_BUFFERING_DISABLE; 
1 |=OMAP_DMA_CCR_EN; 





// 写 相应 的 enable bit 
p —>dma_write(1, CCR, lch); 


// 标 记 该 channel 为 active 状态 
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dma_chan| lch]. flags |= OMAP_DMA_ACTIVE; 


//stop 相应 DMA channel 的 接口 函数 
void omap. stop. dma( int Ich) 
| 

u32 1; 


1=p-—>dma_read(CCR, Ich) ; 
if(IS_DMA_ERRATA(DMA_ERRATA_i541) && 
(1 & OMAP_DMA_CCR_SEL_SRC_DST_SYNC) ) | 
// 这 是 对 source 同步 stop channel 时 bug 的 workaround 


inti=0; 





u32 sys_cf; 


/ * Configure No — Standby * / 

l =p -» dma, read( OCP. SYSCONFIC, lch); 

sys cf zl; 

1 & = ~ DMA, SYSCONFIG. MIDLEMODE MASK ; 

l |= DMA, SYSCONFIG. MIDLEMODE( DMA, IDLEMODE NO IDLE) ; 
p -> dma write(1 , OCP. SYSCONFIC, 0) ; 


] 2 p-» dma, read( CCR, lch); 
l & = -OMAP DMA_ CCR, EN; 
p -> dma write(1, CCR, Ich); 


/ * Wait for sDMA FIFO drain * / 
] 2 p -» dma, read( CCR, lch); 
while(i« 100 && (1 &(OMAP DMA CCR, RD. ACTIVE | OMAP_DMA_CCR_WR_AC- 
TIVE) ) ) | 
udelay(5) ; 
i++; 
l =p -> dma_read( CCR, Ich) ; 
| 
if(i >= 100) 
printk( KERN_ERR "DMA drain did not complete on " 
"Ich % d\n" , lch); 
/ * Restore OCP_SYSCONFIG */ 
p —>dma_write(sys_cf, OCP_SYSCONFIG, lch); 
\ else | 
// 直接 清除 cor 寄存 器 的 enable bit 来 disable channel 
// 从 而 stop 相应 的 channel 
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l & = ~OMAP_DMA_CCR_EN; 
p —>dma_write(1, CCR, Ich); 


if( !omap_dma_in_1510_mode( ) && dma_chan| Ich]. next_Ich ! = -1) | 
// 如 果 是 channel link , 则 要 disable link 中 所 有 的 channel 
// 主 要 是 拆 link 


int next_lch, cur_Ich = lch; 








char dma, chan. link map| dma lch, count | ; 


/清除 相应 的 标记 ,以 便 检查 所 有 的 link 都 可 以 清除 
memset(dma_chan_link_map, 0, sizeof( dma chan link map)); 
do | 


/ * The loop case; we ve been here already */ 





if( dma, chan. link map| cur. Ich ] ) 
break ; 

/ * Mark the current channel * / 

// 标 记 相 应 的 channel 已 经 disable 


dma_chan_link_mapl cur_lch | =1; 











//disable 相应 的 link ,其 中 会 置 channel 的 flag 为 deactive 
disable Ink( cur lch) ; 


// ssi Bj link 
next, Ich = dma, chan[ cur. lch ]. next. ]ch; 
cur. Ich = next, Ich; 


| while(next lch ! = -1); 


// 设 置 channel flag 为 deactive 
dma_chan| lch]. flags & = ~OMAP_DMA_ACTIVE; 


// 下 面 开 始 是 每 个 DMA channel 的 中 断 处 理 相 关 的 函数 
static int omap2_dma_handle_ch(int ch) 


| 





// 首 先 读 取 channel 的 中 断 状态 寄存 带 
u32 status = p -> dma, read( CSR, ch); 


























// 如 果 是 csr 为 0 说 明 是 spurious DMA irqd , 报 伪 中 断 的 错误 
if( 1status ) | 
if( printk_ratelimit( ) ) 
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printk( KERN_WARNING "Spurious DMA IRQ for Ich % d\n" , 
ch) ; 
/清除 DMA 对 MPU 相应 的 channel 的 状态 位 ,以 便 后 续 中 断 处 理 
p -» dma write(1 < ch, IRQSTATUS_LO, ch); 


return 0; 





t 


| 
// channel 没有 分 配 则 报错 
if( unlikely ( dma, chan[ ch]. dev id == -1))| 
if( printk, ratelimit( ) ) 
printk( KERN. WARNING "IRQ % 04x for non — allocated DMA" 
"channel % d\n", status, ch) ; 


return 0; 


} 
//drop dma 处 理 则 报错 ,出 现 该 情况 时 需要 加 速 处 理 
// drop 硬件 逻辑 为 dma_req 来 了 但 是 之 前 还 有 dma_req 没有 处 理 
if( unlikely( status & OMAP_DMA_DROP_IRQ) ) 

printk ( KERN, INFO 





"DMA synchronization event drop occurred with device " 


"%d\n" , dma, chan[ ch]. dev. id) ; 
人/ 如 果 传 输 错误 则 报错 
if( unlikely( status & OMAP2 DMA, TRANS ERR IRQ)) | 
printk( KERN. INFO "DMA transaction error with device % d\n" , 
dma, chan[ ch]. dev. id) ; 
if(IS DMA ERRATA(DMA ERRATA i378) ) | 
/ / yis RR Hp Az HE RRUEUZ disable channel 
// 需 要 手动 disable 


u32 ccr; 











ccr =p -» dma read( CCR, ch); 

cer & = ~OMAP_DMA_CCR_EN; 

p -» dma write(ccr, CCR, ch); 

dma, chan[ ch]. flags & = ~ OMAP. DMA, ACTIVE; 


| 
//secure 和 misaligned error "P Arik fe 
if( unlikely( status & OMAP2_DMA_SECURE_ERR_IRQ) ) 
printk ( KERN. INFO "DMA secure error with device % d\n" , 
dma, chan[ ch ]. dev. id) ; 
if( unlikely ( status & OMAP2 DMA, MISALIGNED ERR, IRQ) ) 
printk( KERN. INFO "DMA misaligned error with device % d\n" , 
dma, chan[ ch ]. dev. id) ; 
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// 38 É& channel status 状态 

p -> dma write( OMAP2 DMA CSR. CLEAR. MASK, CSR, ch); 
// 清 除 对 mpu 的 irq 状态 

p -> dma write(1 << ch, IRQSTATUS I0, ch); 

/ * read back the register to flush the write * / 

/人 /做 读 操 作 实际 为 barrier 保证 完成 

p —> dma_read( IRQSTATUS 10, ch); 





/ * Tf the ch is not chained then chain. id will be -1 */ 
if( dma, chan[ ch]. chain id ! = -1)| 
// 如 果 是 chain, 需 要 对 chain 进行 处 理 
//DM 3730 没有 使 用 chain, 所 以 不 会 到 这 里 
int chain_id = dma_chan[ ch ]. chain_id; 
dma, chan[ ch]. state = DMA, CH, NOTSTARTED; 
if( p -> dma read( CLNK_CTRL, ch) &(1««15)) 
dma, chan[ dma, chan[ ch]. next. linked. ch ]. state = DMA, CH, STARTED; 
if( dma, linked lch[ chain, id |. chain, mode == OMAP DMA, DYNAMIC, CHAIN) 
disable lnk( ch) ; 


if( YKOMAP DMA. CHAIN QEMPTY ( chain. id) ) 
OMAP DMA. CHAIN INCQHEAD( chain. id) ; 


status = p -> dma read( CSR, ch) ; 
// 重 写 status 则 清除 相应 的 状态 bit 
p -» dma write( status, CSR, ch); 
// 调 用 request 或 者 set. dma, callback 时 设置 的 callback 函数 
// 完 成 驱动 的 策略 
if(likely( dma_chan| ch]. callback ! = NULL) ) 


dma_chan| ch]. callback(ch, status, dma, chan[ ch]. data) ; 


return 0; 


/ * STATUS register count is from 1 -32 while our is 0 -31 */ 
//MPU 处 理 DMA channel 中 断 的 接口 函数 


static irqreturn_t omap2_dma_irq_handler( int irq, void * dev, id) 


| 





u32 val, enable_reg; 


int 1; 








// 首 先 读 取 DMA irq status 寄存 需 
val = p -> dma_read( IRQSTATUS_LỌ, 0) ; 
// 为 0 标识 欺骗 中 断 报错 
if( val ==0) | 
if( printk_ratelimit( ) ) 
printk( KERN. WARNING "Spurious DMA IRQ\n" ) ; 
return IRQ_HANDLED; 








| 
// 只 对 已 经 enable 的 中 断 进 行 处 理 
// 要 读 取 irq enable 寄存 需 
enable reg = p -> dma read( IRQENABLE_LO, 0) ; 
// 对 status 进行 处 理 保留 enable 的 中 断 
val & = enable_reg;/ * Dispatch only relevant interrupts * / 
for(i =0; i «dma lch, count && val ! 20; i++) | 
// 移 位 处 理 每 个 置 位 的 channel 
//omap2_dma_handle_ch 为 channel 的 中 断 处理 函 数 
if( val & 1) 
omap2. dma handle ch(i); 














E 


val >=1; 


return IRQ. HANDLED; 


//DMA 于 kernel 的 中 断 处 理 的 接口 ,irqaction 
static struct irqaction omap24xx_dma_irg = | 

. name ="DMA", 

. handler = omap2_dma_irq_handler, 


. flags = IRQF. DISABLED 





E 


4. SDMA 管理 初始 化 及 防止 多 核 冲 突 的 实现 

SDMA 初始 化 还 是 以 platform 驱动 的 形式 存在 ， 而 相应 的 防止 多 核 使 用 DMA 冲突 的 接 
口 是 omap_dma_cmdline_reserve_ch， 原 理 是 通过 启 动 参数 设 定 ARM MPU 保留 的 DMA 逻辑 
channel， 使 得 ARM MPU 只 能 使 用 保留 的 逻辑 channel, 
































//DMA 的 platform_driver 和 platform. device 进行 绑 定 的 接口 ,主要 负责 通过 
//platform_device 的 信息 初始 化 相应 的 管理 实体 
static int devinit omap_system_dma_probe( struct platform, device * pdev) 


| 





int ch, ret 20; 
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int dma_irq; 
char irq_name| 4 | ; 


int irq_rel; 





// 获 得 DMA platform device 的 信息 ,主要 是 resource 以 及 channel BULA chip 的 操作 接口 等 信息 
p = pdev -> dev. platform_data; 
if(!p) | 
dev_err( &pdev -> dev, "96s; System DMA initialized without" 
"platform data\n", func __); 


return — EINVAL; 


// 包 括 chip 级 别 的 操作 接口 等 信息 
d =p —>dma_attr; 


errata =p -> errata; 


// 检 查 是 否 reserve channel, 这些 channel 给 ARM 使 用 
if( (d -> dev. caps & RESERVE CHANNEL) && omap_dma_reserve_channels 
&&( omap. dma, reserve. channels <= dma, lch, count) ) 


d -» Ich. count = omap. dma. reserve. channels ; 


dma, Ich, count =d -»lch, count; 

dma, chan. count = dma, lch, count ; 

// channel 的 管理 实体 在 chip 的 platform. device 的 初始 化 时 候 已 经 分 配 
// 这 里 是 个 指针 

dma_chan =d -> chan; 


enable_1510_mode = d -> dev. caps & ENABLE_1510_MODE; 























if( cpu, class is omap2( ) ) | 
// 分 配 chain 中 的 link 管理 实体 ,DM 3730 上 并 没有 使 用 chain 
dma, linked, lch = kzalloc( sizeof( struct dma_link_info) * 
dma, lch. count, GFP. KERNEL) ; 
if( !dma, linked, lch) | 
ret = - ENOMEM; 





goto exit dma, Ich. fail; 


// F BEDS REA channel 的 管理 实体 进行 初始 化 
spin_lock_init( &dma_chan_lock) ; 





for(ch =0; ch « dma chan, count; ch ++ ) | 


// 首 先 clear 相应 的 每 个 channle 寄存 器 
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omap_clear_dma(ch) ; 
if( cpu, class is omap2( ) ) 
omap2. disable irq lch( ch) ; 


// 进 行 未 分 配 和 未 建 link 的 初始 化 
dma, chan[ ch]. dev. id = -1; 


dma, chan[ ch]. next. ]ch = -1; 


if( ch »26 && enable. 1510. mode) 


continue ; 


人/ 设置 和 性 能 相关 的 ger 参数 ,这 里 的 设置 和 性 能 有 关系 
if( cpu_is_omap2430( ) | cpu_is_omap34xx( ) | cpu_is_omap44xx( ) ) 
omap. dma, set, global, params ( DMA, DEFAULT. ARB. RATE, DMA, DEFAULT. FIFO — 
DEPTH, 0); 





// 对 中 断 进行 初始 化 
if(cpu_class_is_omap2( ) | 
// 首 先 获得 中 断 号 


strepy(irq_name, "0" ); 





dma_irq = platform_get_irq_byname(pdev, irq name) ; 
if( dma, irq <0) | 
dev. err( &pdev -> dev, "failed; request IRQ 96 d" , dma_irq) ; 
goto exit dma, lch fail; 
| 
/设置 中 断 处 理 接口 
ret = setup_irq(dma_irq, &omap24xx_dma_irq) ; 
if( ret) | 
dev, err( &pdev -> dev, "set up failed for IRQ 96 d" 
"for DMA( error 96 d) Xn" , dma_irq, ret); 


goto exit dma, Ich. fail; 








/ * reserve dma channels 0 and 1 in high security devices * / 
if( cpu, is. omap34xx( ) && 
(omap. type( ) ! = OMAP2 DEVICE TYPE GP))| 
//omap3hs 设备 要 保留 channel 0 和 1 给 HS ROM code 
printk( KERN. INFO " Reserving DMA channels 0 and 1 for " 
"HS ROM code\n" ) ; 
dma, chan[ 0]. dev. id 20; 
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dma, chan[ 1 ]. dev_id =1; 
f 
// chip 的 DMA 能 力 显 示 
p -» show, dma, caps( ) ; 


return 0; 


exit dma irq fail: 
dev. err( &pdev —» dev, " unable to request IRQ 96 d" 
"for DMA( error 26 d) n" , dma_irq, ret); 
for( irq. rel 20; irq rel « ch; irq_rel ++ ) | 
dma, irq = platform. get, irq( pdev, irq. rel) ; 


free irq( dma, irq, (void * ) (irq rel +1) ) ; 


exit dma, lch, fail; 
kfree( p) ; 
kfree( d) ; 
kfree( dma, chan) ; 


return ret ; 























//omap DMA 的 platform. driver 接口 用 于 相关 的 管理 实体 的 初始 化 和 释放 


static struct platform. driver omap_system_dma_driver = | 


. probe = omap. system. dma, probe, 
. remove = omap. system. dma, remove , 
. driver EX 

. name -"omap. dma system" 


m 
E 


J * 
* Reserve the omap SDMA channels using cmdline bootarg 
* "omap_dma_reserve_ch=". The valid range is 1 to 32 
*/ 


// 为 bootargs 保留 的 DMA channel reserve 的 接口 
static int — init omap. dma, emdline reserve, ch(char * str) 


| 





if( get. option( &str, &omap. dma reserve, channels) ! = 1 ) 
omap. dma, reserve channels 20; 
retum 1; 


| 


. setup("omap. dma reserve ch =" , omap_dma_cmdline_reserve_ch) ; 
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DMA 是 很 多 驱动 都 需要 使 用 的 基础 功能 之 一 ， 以 上 进行 了 详细 的 代码 级 分 析 。 以 上 的 
代码 与 DMA engine 框架 的 功能 类 似 ， 可 以 看 做 是 DMA engine 的 芯片 级 实现 。 需 要 注意 的 是 
DM 816X 系列 芯片 内 部 不 是 SDMA 而 是 EDMA， 与 SDMA 差别 主要 是 操作 的 寄存 器 不 同 ， 
但 是 由 于 相应 的 设备 驱动 已 经 使 用 omap 的 DMA 接口 实现 ， 最 简单 的 移植 就 是 将 EDMA 的 
操作 以 omap 的 DMA 接口 封装 ， 相 应 的 sdma2edma. c 就 是 实现 该 功能 。 





4.6 时 钟 (clock) 


4.6.1 clock 管理 基本 需求 


时 钟 是 便 件 模块 的 基础 ， 硬 件 模块 要 想 正 常 的 工作 都 需要 系统 为 其 提供 时 钟 。 当 然 系统 
很 难为 每 个 外 设 从 单独 的 时 钟 源 提 供需 要 的 时 钟 ， 而 是 通过 如 图 2-8 所 示 的 时 钟 树 的 方式 
为 每 个 硬件 模块 提供 所 需 的 时 钟 。 

任何 一 个 时 钟 应 该 都 可 以 开关 ， 设置 频率 。 由 于 某 个 时 钟 是 在 时 钟 树 上 的 一 点 ， 所 以 当 
改变 某 个 时 钟 频率 后 会 影响 到 该 时 钟 下 层 的 时 钟 频率 ， 这 就 需要 时 钟 管理 以 层次 的 方式 进 
行 ， 实 现 一 种 树 状 的 管理 。 

实现 了 时 钟 的 管理 ， 就 需要 框架 提供 正确 查找 时 钟 的 功能 。 总 体 来 说 ， 时 钟 需要 能 够 进 
行 组 织 管理 ， 要 能 查找 、 能 设置 ， 设 置 要 有 继承 性 。 另 外 作为 一 种 资源 ，clock 实际 是 设备 
模块 的 一 部 分 ， 所 以 时 钟 还 要 能 够 和 设备 产生 关联 ， 相 应 的 也 要 有 使 用 计数 的 管理 。 


4.6.2 clock 管理 框架 介绍 


1. clock 控制 结构 及 相关 接口 

Linux 内 核 中 时 钟 的 管理 也 是 经 历 了 时 间 的 演进 。 早 期 的 时 钟 管理 ，Linux 内 核 只 是 提供 
了 接口 的 声明 ， 并 没有 进行 接口 的 定义 和 实现 ， 相 应 的 声明 是 在 linux/include/linux/clk. h 
中 ， 这 些 声明 需要 体系 结构 代码 进行 具体 实现 ， 这 些 声 明 为 框架 和 具体 的 实现 指明 了 方向 。 
先 来 看 看 这 些 声明 及 其 具体 的 意义 (保留 英文 注释 ， 因 为 解释 已 经 足够 详细 ) 。 















































/* 
* struct clk — an machine class defined object/cookie. 
*/ 
struct clk ; 
fd 
* clk get — lookup and obtain a reference to a clock producer. 
* (9 dev: device for clock "consumer" 
* (9 id: clock comsumer ID 
* 
* Returns a struct clk corresponding to the clock producer, or 
* valid IS ERR( ) condition containing errno. The implementation 
* uses @ dev and @ id to determine the clock consumer, and thereby 
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* 


the clock producer. (IOW, @ id may be identical strings, but 
* clk_get may return different clock producers depending on @ dev. ) 


* Drivers must assume that the clock source is not enabled. 


* 


clk get should not be called from within interrupt context. 
*/ 


struct clk * clk_get(struct device * dev, const char * id) ; 


/ x x 
* clk enable — inform the system when the clock source should be running. 


* @clk: clock source 


* 


If the clock can not be enabled/ disabled, this should return success. 
* 
* Returns success(0) or negative errno. 
*/ 

int clk enable( struct clk * clk) ; 


/* 
* clk disable — inform the system when the clock source is no longer required. 


* (Q9 clk; clock source 


* Inform the system that a clock source is no longer required by 


* a driver and may be shut down. 


* Implementation detail; if the clock source is shared between 
* multiple drivers, clk_enable( ) calls must be balanced by the 
* same number of clk_disable( ) calls for the clock source to be 
* disabled. 
*/ 

void clk_disable( struct clk * clk) ; 


/* x 
* clk get rate — obtain the current clock rate( in Hz)for a clock source. 
* This is only valid once the clock source has been enabled. 
* @clk: clock source 
*/ 
unsigned long clk get rate(struct clk * clk) ; 


Js & 


* clk put— "free" the clock source 
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* 


@ clk; clock source 


* Note; drivers must ensure that all clk enable calls made on this 


* 


clock source are balanced by clk_disable calls prior to calling 


* 


this function. 


* 


clk_put should not be called from within interrupt context. 
*/ 
void clk put(struct clk * clk); 


/ * 
* The remaining APIs are optional for machine class support. 
*/ 


J e 


* clk_round_rate — adjust a rate to the exact rate a clock can provide 


* 


@ clk; clock source 


* @ rate: desired clock rate in Hz 


* Returns rounded clock rate in Hz, or negative errno. 
*/ 


long clk round, rate( struct clk * clk, unsigned long rate) ; 


/ x ox 
* clk set rate — set the clock rate for a clock source 
* (Q9 clk; clock source 
* @ rate; desired clock rate in Hz 
* 
* Returns success(0) or negative errno. 
*/ 


int elk set, rate( struct clk * clk, unsigned long rate) ; 


/* x 
* clk_set_parent — set the parent clock source for this clock 
* @ clk; clock source 
* @ parent: parent clock source 


* 


* Returns success(0) or negative errno. 
*/ 


int clk set, parent(struct clk * clk, struct clk * parent) ; 


Je & 
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* 


clk get parent — get the parent clock source for this clock 


* @clk: clock source 


* Returns struct clk corresponding to parent clock source, or 


* 


valid IS. ERR( ) condition containing errno. 
*/ 


struct clk * clk_get_parent( struct clk * clk); 


/* x 
* clk_get_sys — get a clock based upon the device name 
* @ dev_ id: device name 


* (9 con id: connection ID 


* Returns a struct clk corresponding to the clock producer, or 

* valid IS ERR( ) condition containing errno. The implementation 
* uses @ dev id and @ con, id to determine the clock consumer, and 
* thereby the clock producer. In contrast to clk, get( ) this function 


* takes the device name instead of the device itself for identification. 


* Drivers must assume that the clock source is not enabled. 

* 

* clk get sys should not be called from within interrupt context. 
*/ 


struct clk * clk get sys(const char * dev, id, const char * con id); 


/* x 
* clk add, alias — add a new clock alias 
* (alias; name for clock alias 
* (alias dev. name; device name 
* @id: platform specific clock name 


* (9 dev; device 


* 


Allows using generic clock names for drivers by adding a new alias. 
* Assumes clkdev, see clkdev. h for more info. 
*/ 
int clk add, alias(const char * alias, const char * alias, dev, name, char * id, 


struct device * dev); 








Linux 内 核 规定 了 这 些 接口 的 形式 ， 特 别 是 时 钟 的 管理 结构 struct clk 也 只 是 进行 了 声 
明 ， 它 们 都 需要 在 体系 结构 进行 具体 的 定义 。 从 这 些 声明 中 可 见 ， 体 系 结构 代码 需要 实现 时 
钟 的 获得 、 频 率 设置 、 引 用 计数 管理 、 管 理 层次 的 设置 等 功能 。 这 些 功能 符合 之 前 对 需求 的 
讨论 。 当 然 这 些 接 口 并 不 都 需要 实现 。 驱 动 设备 的 开发 者 只 要 调用 上 面 的 接口 进行 相关 的 操 
作 即 可 ， 不 必 关 心 具 体 的 实现 。 
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Linux 内 核 这 样 的 设计 给 各 个 体系 结构 很 大 的 自主 设计 自由 ， 主 要 是 因为 包括 Intel 在 内 的 
很 多 处 理 器 ， 其 相应 的 时 钟 树 并 不 复杂 。 这 样 只 需要 进行 统一 的 声明 并 由 体系 结构 自己 实现 。 

2. clock 查找 和 引用 计数 框架 

上 面 的 接口 在 ARM 体系 结构 中 实现 了 通用 的 时 钟 查找 和 引用 计数 的 框架 。 具 体 的 实现 
在 arch/arm/common/clkdev. c 中 。 针 对 时 钟 查找 ，ARM 体系 结构 定义 了 struct clk_lookup 来 
实现 。clk_lookup， 顾名思义 是 用 来 查找 struct clk 结构 的 。 有 了 它 ， 就 可 以 通过 设备 名 或 时 
钟 的 名 字 来 找到 相应 的 struct clk 结构 。clk_lookup 的 组 织 框图 如 图 4-46 所 示 。 
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图 4-46  clk lookup 的 组 织 框图 


从 图 4-46 可 见 ，clk_lookup 组 织 成 链表 ， 相 应 的 每 个 节点 都 会 指向 一 个 struct clk, iX 
样 就 可 以 通过 比 对 clk_lookup 中 的 dev. id 和 con. id 来 找到 正确 的 struct clk 了 。ARM 体系 结 
构 中 通过 clkdev_add 将 已 经 定义 的 clk_lookup 加 入 链表 进行 管理 ， 相 应 的 需要 芯片 特定 的 代 
人 码 对 所 有 时 钟 对 应 的 clk_lookup 都 进行 定义 。 

Linux 内 核 中 其 他 的 时 钟 管理 接口 是 在 芯片 特 殊 代 码 中 实现 的 。 

随 着 SoC 的 发 展 以 及 电源 管理 的 需要 ， 时 钟 树 变 得 越 来 越 复 杂 ， 内 核 也 越 来 越 需要 统一 
时 钟 管理 框架 。 新 的 Linux 内 核 选 择 了 芯片 厂商 ST 提供 的 时 钟 框架 作为 通用 时 钟 管理 框架 
(common clock) ， 其 中 对 于 时 钟 查找 沿用 ARM 体系 结构 的 clk_lookup， 并 进行 了 些 修改 ， 
struct clk 及 其 他 接口 都 使 用 ST 的 实现 。common clock 框架 与 TI 芯片 的 时 钟 管理 框架 的 实现 
整体 上 是 一 致 的 ， 所 以 这 里 不 进行 详细 介绍 ， 了 解 了 TI 芯片 的 时 钟 管 理 框架 之 后 ， 再 看 
common clock 的 框架 就 比较 容易 理解 了 。 


4.6.3 TI 芯片 clock 管理 相关 实现 详解 


TLGA (包括 DM 3730 和 DM 816X) 时 钟 管理 框架 的 实现 也 是 分 层次 的 。 在 上 层 实 现 
T Linux 内 核 提供 的 接口 函数 作为 抽象 层 ， 供 其 他 模块 使 用 ;底层 则 是 和 芯片 相关 的 具体 接 
口 实现 。 无 论 哪 一 层 ， 相 应 的 核心 结构 都 是 struct clk， 该 结构 在 arch/arm/plat - omap/in- 
clude/plat/clock. h 中 定义 ， 具 体内 容 如 下 : 






































struct clk | 
struct list_head node; 


const struct clkops * ops; 
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ount; 操作 接口 ;以 及 特定 时 钟 类 型 相关 的 


const char * name; 


struct clk * parent ; 
struct list_head children ; 
struct list_head sibling; /* node for children * / 
unsigned long rate ; 
void — iomem * enable reg; 
unsigned long ( * recale) (struct clk * ) ; 
int ( ** set, rate) (struct clk * , unsigned long) ; 
long ( ** round, rate) (struct clk * , unsigned long) ; 
void ( ** init) (struct clk * ) ; 
u8 enable_bit; 
s8 usecount ; 
u8 fixed_div; 
u8 flags; 
#ifdef CONFIG. ARCH, OMAP2PLUS 
void _ iomem * clksel_reg; 
u32 clksel_mask; 


const struct clksel — * clksel; 
struct dpll, data * dpll, data; 
const char * clkdm, name; 


struct clockdomain * clkdm; 


#else 
u8 rate. offset ; 
u8 src. offset; 
#endif 


#if defined( CONFIG_PM_DEBUG) && defined( CONFIG_DEBUG_FS) 


struct dentry * dent;/ * For visible tree hierarchy * / 


#endif 
E 


其 中 包括 了 和 树 状 管理 相关 的 属性 parent, children 和 sibling; 使 用 计数 的 属性 usec- 








属性 ， 如 clksel, dpll data 等 。 这 里 包含 了 完整 


的 信息 。 时 钟 管 理 的 具体 实现 就 是 围绕 着 该 数据 结构 展开 的 。 


中 规定 的 一 些 接口 ， 代 码 分 析 如 下 : 
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下 面 按照 层次 来 介绍 时 钟 管理 。 


1. 抽象 层 实现 





相应 的 抽象 实现 是 在 linux/arch/arm/plat- omap/clock. c 文件 中 ， 具 体 实现 了 Linux 内 核 


// 下 面 是 Linux 标准 的 clk API 的 实现 ,定义 在 include/linux/clk. h 中 


// 这 些 API 都 做 了 必要 的 lock 保护 ,可 以 在 SMP 和 irq 等 所 有 的 上 下 文 调 























ay 





// 这 些 API 会 调用 chip 具体 的 clock 的 操作 





// 相 应 clock enable 的 接口 


int clk_enable( struct clk * clk) 


| 
l 


//clock disable 的 接口 


void 


| 


out; 





/f/3) 


unsigned long flags; 


int ret 20; 


if(clk == NULL | IS ERR(cIk) ) 
return. — EINVAL; 


spin. lock, irqsave( &clockfw. lock, flags) ; 
// 调 用 芯片 具体 的 操作 接口 
if(arch_clock -> clk_enable) 

ret = arch, clock -> clk_enable( clk) ; 





spin, unlock, irqrestore( &clockfw_lock, flags) ; 


return ret; 





clk disable( struct clk * clk) 
unsigned long flags ; 


if(clk == NULL || IS_ERR(clk) ) 


return ; 


spin, lock, irqsave( &clockfw_lock, flags) ; 


if( clk -> usecount ==0) | 


pr. err( " Trying disable clock 96s with 0 usecount\n" , 


clk -> name) ; 
WARN. ON(1) ; 
goto out; 
| 
// 调 用 芯片 具体 的 操作 接口 
if( arch_clock —> clk_disable) 
arch_clock —> clk_disable( clk) ; 


spin_unlock_irqrestore ( &clockfw_lock, flags) ; 


R4 clock AY rate 
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unsigned long clk_get_rate(struct clk * clk) 
| 
unsigned long flags; 


unsigned long ret =0; 


if(clk == NULL || IS ERR(cIk) ) 


return 0; 


spin, lock, irqsave( &clockfw. lock, flags) ; 
ret = clk —> rate; 


spin_unlock_irgrestore( &clockfw_lock , flags) ; 


return ret; 


/ * 

* Optional clock functions defined in include/linux/clk. h 

* / 
// 根 据 要 设置 的 clock 的 rate 以 及 chip 的 special 得 出 chip 能 接受 的 最 接近 的 rate 
// 注 意 这 里 只 是 计算 近似 rate ,并 不 进行 实际 的 设置 ,设置 在 clk_set_rate 中 进行 
long clk_round_rate( struct clk * clk, unsigned long rate) 


| 








unsigned long flags; 


long ret 20; 


if(clk == NULL | IS ERR(cIk) ) 


return ret ; 


spin, lock, irqsave( &clockfw. lock, flags) ; 
// 调 用 芯片 具体 的 操作 接口 


if( arch. clock -> clk_round_rate ) 





ret = arch, clock ->clk_round_rate(clk，rate ) ; 


spin_unlock_irqrestore( &clockfw_lock , flags) ; 


return ret; 





// 设 置 clock 相应 的 rate 
int clk_set_rate( struct clk * clk, unsigned long rate) 


| 




















unsigned long flags; 


int ret = — EINVAL; 
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if(clk == NULL || IS_ERR(clk) ) 


return ret; 


spin, lock, irqsave( &clockfw_lock, flags) ; 
// 调 用 芯片 具体 的 操作 接口 
if( arch_clock -> clk_set_rate) 
ret = arch, clock —>clk_set_rate(clk, rate) ; 
if( ret 220) | 
// 设 置 rate 成 功 , 则 该 clock 的 rate 要 重新 计算 一 下 ,保证 正确 
if( clk ->recalc) 
clk —> rate = clk —» recale(clk) ; 
// 由 于 clock rate 变化 ,相应 的 clock 下 面 的 子 clock 全 要 重新 计算 rate 


propagate_rate(clk) ; 





| 


spin, unlock, irqrestore( &clockfw_lock, flags) ; 


return ret; 


//X clock 设置 新 的 parent 
int clk set parent(struct clk * clk, struct clk * parent) 
| 


unsigned long flags; 
int ret = — EINVAL; 


if(clk == NULL || IS_ERR(clk) || parent == NULL || IS ERR( parent) ) 


return ret; 


spin, lock, irqsave( &clockfw. lock, flags) ; 
// 只 有 clock 的 使 用 计数 为 0 AFT LAKE, enable/disable 时 会 对 计数 进行 操作 
if( clk ->usecount ==0) | 

// chip 相关 的 set. parent 

if( arch. clock -> clk. set. parent) 








ret = arch, clock -> clk set. parent( clk, parent) ; 
if( ret 220) | 
/7 正确 设置 则 需要 重新 计算 rate ,包括 子 clock 的 rate 计算 
if( clk -> recalc ) 
clk —» rate = clk —» recale( clk) ; 


propagate_rate(clk) ; 


| else 
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ret = — EBUSY; 


spin, unlock, irqrestore( &clockfw_lock, flags) ; 


return ret; 





// 获 得 parent clock 
struct clk * clk get, parent( struct clk * clk) 


| 


return clk —> parent; 


| 


2. 芯片 时 钟 接口 具体 实现 
在 抽象 层 看 到 很 多 接口 都 是 调用 芯片 的 具体 实现 来 执行 的 ，DM 3730 和 DM 816X 相关 
的 具体 实现 是 在 mach - omap2/clock. c 中 操作 接口 综合 成 clk. functions, 


struct clk_functions omap2_clk_functions = | 


. clk_enable =omap2_clk_enable, 

. clk disable -omap2. clk, disable, 

. clk. round. rate = omap2. clk round rate, 

. clk. set. rate -omap2. clk set, rate, 

. clk set. parent = omap2. clk set parent, 

. clk disable unused = omap2. clk disable unused, 


l; 
相应 的 接口 实现 详细 分 析 如 下 : 


// 为 plat- omap clock 框架 提供 的 clock disable 函数 

// 实 际 的 操作 逻辑 为 先 disable clock ,如 果 必 要 使 clock domain 可 idle ,最 后 parent disable 
void omap2_clk_disable( struct clk * clk) 

| 








// 使 用 计数 为 0 时, 才 真 正 进行 clock 的 disable 操作 . 
if( clk -> usecount ==0)| 
WARN(1, "clock; 96s; omap2_clk_disable() called, but usecount " 
"already 0?" , clk -> name) ; 


return; 


pr_debug( "clock: 96s; decrementing usecount\n" , clk -> name) ; 


clk —» usecount - — ; 


if( clk -> usecount » 0) 
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return ; 


pr debug(" clock; 96s; disabling in hardware\n" , clk -> name) ; 


// 计 数 为 0, 调 用 clkops 的 disable 函数 . 
clk -> ops -> disable( clk) ; 





// PES I] clock domain 也 要 disable 操作 ,主要 是 保证 相应 的 clock domain 的 idle mode 可 以 使 
// 相 应 的 clock domain( 包括 power domain) 人 处 于 idle 状态 ,从 而 相应 的 idle 功能 也 要 等 待 power 
//domain 状态 转换 并 记录 .如果 hwsup 模式 为 autoidle, 可 以 通过 增加 或 移 除 与 mpu daomin 
// 的 dependency 关系 使 得 module active 或 者 idle. 
if( clk -> clkdm) 

omap2_clkdm_clk_disable( clk -> clkdm, clk) ; 











//parent clock 的 引用 计数 同样 要 减 ,都 在 disable 中 进行 
if( clk -> parent) 
omap2_clk_disable( clk -> parent) ; 











// 主 要 是 为 plat — omap 提供 的 clock eanble 函数 ,也 可 以 被 其 他 模块 调用 。 实 际 的 操作 逻辑 为 parent 要 
// enable ,clock 所 属 的 clock domain 要 可 以 active ,然后 才能 enable 该 clock Jf- ARIE clock domain 
// JJ active 状态 

int omap2_clk_enable(struct clk * clk) 


| 














int ret; 


pr_debug( "clock: 96s; incrementing usecount\n" , clk -> name) ; 


clk -> usecount ++ ; 


if( clk -> usecount > 1) 


return 0; 


// 第 一 次 使 用 需要 真正 的 enable 操作 


pr_debug( "clock: 96s; enabling in hardware\n" , clk -> name) ; 





// 首 先 parent clock 要 进行 enable 操作 . 
if( clk -> parent) | 











ret = omap2. clk enable( clk -> parent) ; 
if( ret) | 
WARN(I, "clock: 96s; could not enable parent 96s; 96 d\n", 
clk -> name, clk -> parent -> name, ret); 


goto oce errl ; 
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/7/ 所 属 的 clock domain 要 enable, 主要 是 保证 相应 的 clock domain 的 idle mode 可 以 使 相应 的 
//clock domain( 包括 power domain) Xb active 状态 ,从 而 激活 功能 ,相应 的 也 要 等 待 power 
//domain 状态 转换 并 记录 .如果 hwsup 模式 为 autoidle, 可 以 通过 增加 或 移 除 与 mpu daomin 
// 的 dependency 关系 使 得 module active 或 者 idle. 
if( clk —>clkdm) | 

ret = omap2_clkdm_clk_enable( clk -> clkdm, clk); 

if( ret) | 

WARN(1, "clock: 96s: could not enable clockdomain 96s; " 
"06 d\n", clk -> name, clk -> clkdm -> name, ret); 











goto oce_err2 ; 


// 此 时 enable 该 clock , 38 4$ A omap2, dflt clk enable , 3E 9$ 4&1 2j 7-45 enable 位 置 位 
ret = clk —> ops -> enable( clk) ; 
if( ret) | 

WARN(1, "clock; 96s; could not enable; 96 d\n", clk -> name, ret); 





goto oce_err3 ; 


return 0; 


// 中 间 过 程 如 果 失 败 , 进 行 相应 的 回 退 操作 . 
oce. err3 ; 
if( clk -> clkdm) 
omap2 clkdm clk, disable( clk -> clkdm, clk) ; 





oce. err2 ; 
if( clk -> parent) 
omap2_clk_disable( clk -> parent) ; 
oce_errl ; 


clk -> usecount —— ; 


return ret; 


/ * Given a clock and a rate apply a clock specific rounding function * / 
// 3&5 clock 能 接受 的 接近 并 小 于 所 期 望 rate 的 频率 ,返回 得 到 的 频率 值 ,并 不 做 设置 
long omap2_clk_round_rate( struct clk * clk, unsigned long rate) 


| 














232 


if( clk —» round, rate) 


return clk —> round, rate( clk, rate) ; 


return clk —> rate; 


/ * Set the clock rate for a clock source * / 
// 设 置 指定 的 rate 
int omap2_clk_set_rate(struct clk * clk, unsigned long rate) 


| 























int ret = — EINVAL; 
pr_debug( "clock: set, rate for clock %s to rate %ld\n" , clk -> name, rate) ; 


/ * dpll_ck, core ck, virt prem set; plus all clksel clocks */ 





if( clk -> set. rate) 


ret = clk —» set, rate( clk, rate) ; 


return ret; 

















// 当 需要 改变 clock 的 source 时 钟 的 时 候 使 用 ,设置 新 的 parent 
int omap2_clk_set_parent( struct clk * clk, struct clk * new, parent) 


| 




















if( lclk ->clksel) 
return — EINVAL; 


if( clk -> parent == new. parent) 


return 0; 


return omap2. clksel set  parent( clk, new. parent) ; 


pe 
* OMAP2 + clock reset and init functions 
*/ 


#ifdef CONFIG OMAP RESET CLOCKS 
// 405% omap chip 的 clock 没有 被 使 用 , 则 disable 相应 的 clock 的 接口 函数 
void omap2_clk_disable_unused( struct clk * clk) 


| 





u32 regval32 v; 
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v = (clk -> flags & INVERT_ENABLE) ? 


(1 «clk -> enable_bit) : 


regval32 = raw, readl( clk -> enable, reg) ; 


if( (regval32 &(1 << clk -> enable, bit) ) 


return; 


pr. debug( " Disabling unused clock \" % s 

if( cpu_is_omap34xx( ) ) | 
omap2_clk_enable( clk) ; 
omap2_clk_disable( clk) ; 

| else | 
clk -> ops -> disable( clk) ; 

| 

if( clk -> clkdm ! = NULL) 


=I v) 


NU \n" A 


clk -> name) ; 


pwrdm. clkdm. state switch( clk -> clkdm) ; 


} 
#endif 


从 代码 中 可 见 ， 对 clock 的 操作 中 还 要 设置 上 层 的 clock domain ， 这 符合 芯片 的 电源 管理 


设计 框架 。 
3. 不 同时 钟 类 型 的 具体 实现 


由 之 前 的 代码 和 struct clk 中 可 见 ， 操 作 接 口 有 两 种 ， 一 种 是 在 struct clkops 中 表示 的 ， 
另外 一 种 是 直接 在 struct clk 中 的 ， 如 set rate 等 。 这 是 为 什么 呢 ? 仔细 看 struct clkops 中 的 
操作 接口 是 和 时 钟 enable 和 disable 相关 的 ， 而 struct clk 中 的 操作 接口 是 和 频率 设 定 相关 的 。 


把 它们 分 开 是 因为 这 是 两 种 完全 不 同 的 操作 类 


型 。 对 enable 和 disable 相关 的 操作 单独 管理 


是 由 于 很 多 模块 会 有 不 止 一 种 时 钟 ， 通 常会 有 接口 时 钟 和 功能 时 钟 ， 而 设备 要 能 使 用 ， 需 要 





在 enable 某 种 时 钟 时 伴随 着 enable 4E Bj 4K f] 





和 时钟 ; 或 者 某 些 时 钟 是 由 模块 对 外 产生 的 ， 


在 enable 时 需要 等 待 相 应 的 模块 到 某 种 状态 时 才 是 真正 的 enable， 只 有 等 待 到 相应 的 状态 时 


相关 的 操作 才 完 整 。 
操作 即 可 。 








而 对 时 钟 频率 的 操作 则 相对 直接 ， 只 要 根据 不 同 的 时 钟 类 型 进行 正确 的 


DM 3730 提供 了 几 类 enable 和 disable 的 操作 接口 ， 具 体 如 下 : 


const struct clkops clkops_omap2_dflt_wait = | 
=omap2_dflt_clk_enable, 

=omap2_dflt_clk_disable, 

-omap2 clk dflt find 


. enable 

. disable 

. find. companion 

. find. idlest 
j3 


const struct clkops clkops_omap2_dflt = | 
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. companion, 


= omap2_clk_dflt_find_idlest, 


. enable = omap2. dflt clk enable, 
. disable = omap2 dflt clk disable, 
E 


可 见 主要 的 接口 是 enable 和 disable。 下 面 来 进行 详细 分 析 ， 在 分 析 之 前 先进 行 说 明 ， 
相应 的 接口 主要 操作 的 寄存 器 是 功能 时 钟 使 能 FCLKEN 、 接 口 时 钟 使 能 ICLKEN 和 状态 检查 
IDLEST 等 寄存 器 。 





// 默 认 的 clock enable 函数 
int omap2_dflt_clk_enable( struct clk * clk) 
| 

u32 v; 


if( unlikely( clk -> enable reg == NULL) ) | 
pr_err(" clock. c; Enable for 96s without enable code\n" , 
clk -> name) ; 


return 0;/ * REVISIT: -EINVAL */ 











// 读 取 enable 寄存 器 的 值 ,并 根据 flag 标识 来 设置 enable 相应 的 clock 
//INVERT. ENABLE 标识 0 为 enable 
v= raw, readl( clk ->enable_ reg) ; 
if( clk -> flags & INVERT. ENABLE) 
v & = ~(1 «clk -> enable, bit) ; 














else 
v |=(1 « clk -> enable. bit) ; 


. raw, writel( v, clk -> enable reg) ; 


// 设 置 barrier 来 保证 之 后 的 操作 该 clock 已 经 enable 
v= raw, readl(clk —>enable_reg) ;/ * OCP barrier * / 





// 如 果 有 IDLEST 相关 的 操作 ,说 明 要 等 待 IDLEST 状态 标识 module 为 ready 
if( clk -> ops —> find, idlest) 





omap2. module, wait ready( clk) ; 





return 0; 


// BRA RS clock disable PR 
void omap2. dflt, clk disable( struct clk * clk) 
| 

u32 v; 


235 


236 


if( !clk —» enable reg) | 
/x 
*' Independent here refers to a clock which is not 
* controlled by its parent. 
*/ 
printk( KERN, ERR "clock; clk, disable called on independent " 
"clock 96s which has no enable reg" , clk -> name) ; 


return ; 


// 读 取 enable 寄存 器 并 设置 为 disable 
v= raw, readl(clk -> enable. reg) ; 
if( clk -> flags & INVERT. ENABLE) 
v |=(1 « clk -> enable. bit) ; 
else 
v & = ~(1 «clk -> enable, bit) ; 
. raw, writel( v, clk -> enable reg) ; 
/ * No OCP barrier needed here since it is a disable operation * / 


// disable 操作 不 需要 barrier 


//#4% companion clock 的 地 址 和 相应 的 enable bit. companion clock 就 是 

// 转 换 CM_ICLKEN * <-> CM_FCLKEN * 

// 有 些 module 是 没有 companion clock ,比如 mailbox 只 有 interface clock 的 模块 
void omap2_clk_dflt find_companion( struct clk *clk, void — iomem * * other reg, 


u8 * other_bit) 
u32 r; 


/* 
* Convert CM_ICLKEN * «—» CM FCLKEN *. This conversion assumes 
* it s just a matter of XORing the bits. 
*/ 

// 转 换 FCLKEN 和 ICLKEN ,并 返回 寄存 器 地 址 和 相应 的 位 域 

r-(( force u32) clk -> enable, reg ^( CM_FCLKEN ^ CM_ICLKEN) ) ; 


* other reg = ( — force void — iomem * )r; 


* other. bit = clk -> enable, bit ; 


// 返 回 IDLEST 相关 的 寄存 器 位 域 ,以 及 非 ready to access 状态 时 的 值 . 





// 这 里 假设 IDLEST 所 在 的 寄存 器 和 FCLKEN 有 对 应 关系 ,只 做 简单 的 偏 移 即 可 





// 但 有 些 module 不 是 这 样 
void omap2_clk_dflt_find_idlest( struct clk * clk, void _iomem * * idlest reg, 
u8 * idlest_bit, u8 * idlest_val) 


u32 r; 


r-((( force u32) clk -> enable reg & ~ Oxf0) | 0x20) ; 
*idlest reg 2 ( — force void iomem * )r; 


* idlest. bit = clk -> enable, bit; 


/* 
* 24xx uses 0 to indicate not ready, and 1 to indicate ready. 
* 34xx reverses this, just to keep us on our toes 
* AM35xx uses both, depending on the module. 
*/ 
// 返 回 指 示 not ready 的 值 omap3 该 值 为 1 
if( cpu_is_omap24xx( ) ) 
* idlest_val = OMAP24XX_CM_IDLEST_VAL; 
else if( cpu. is omap34xx( ) ) 
* idlest_val = OMAP34XX CM IDLEST VAL; 
else 


BUG() ; 





针对 时 钟 频率 的 操作 ， 则 要 考虑 两 种 类 型 的 时 钟 ， 分 别 是 通过 寄存 器 选 # 


dpll clock ， 这 两 种 类 型 的 时 钟 对 应 频率 的 操作 是 完全 不 同 的 。 
先 看 看 通过 寄存 右 选 择 的 时 钟 相关 的 操作 接口 实现 . 








// 所 谓 clksel clock 就 是 符合 下 面条 件 的 clock 
//@ parent clock 不 是 固定 的 

//Q BE divider 因子 的 clock 

//GQ) WA Be 








ERY clock 和 





// 其 中 parent 以 及 mux divider 的 设置 都 是 在 struct clksel * data structures 
//multiplexer 就 是 对 parent 的 选择 ,相应 的 divider 存在 与 parent 关联 的 结构 clksel_rate 中 
// PAF clock 以 及 其 rate 属性 并 不 是 所 有 SOC 都 相同 ,为 了 保证 代码 重用 ,通过 cpu_mask 描述 究 


























// 竞 是 哪个 SOC ,相应 的 rate 中 有 flag 表明 那个 SOC 支持 该 值 


//clksel_reg 寄存 器 地 址 和 clksel_mask 都 在 struct clksel 中 





/7 实际 的 物理 寄存 器 是 PRCM 中 的 CM 模块 的 各 个 module 的 clksel 寄存 器 ,比如 MPU_CM IVA_CM 
// 等 ,PRCM 中 的 PRM 也 有 clock 相关 的 寄存 器 Clock_Control_Reg_PRM ,其 中 也 包含 clksel 寄存 器 
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// 设 置 clksel clock 的 rate. AA struct clk 中 有 clksel 和 clksel_mask 7 Æ clksel 类 型 的 clock 
int omap2_clksel_set_rate( struct clk * clk, unsigned long rate) 


| 




















u32 field val, validrate, new. div 20; 


if( lclk -> clksel || clk -> clksel_mask ) 
return. — EINVAL; 


// 首 先 验 证 获得 的 rate 是 否 符合 


validrate = omap2_clksel_round_rate_div( clk, rate, &new_div) ; 





if( validrate | = rate) 
return. — EINVAL; 


// 获 得 相应 的 寄存 顺应 该 填写 的 值 
field. val = _divisor_to_clksel( clk, new_div) ; 
if(field_val == ~0) 

return — EINVAL; 


// 写 寄存 器 ,并 配置 struct clk 的 rate 值 
_write_clksel_reg( clk, field. val) ; 


clk —> rate = clk —» parent —> rate/new. div; 
pr debug(" clock; 96s; set rate to 96ld Yn" , clk -> name, clk -> rate) ; 


return 0; 





// 当 前 omap clock 代码 假设 parent 的 设置 都 是 clksel 类 型 clock 

// BAA clksel clock 可 以 设置 parent 

// 43 clock 设置 新 的 parent 

int omap2_clksel_set_parent(struct clk * clk, struct clk ** new. parent) 


| 























u32 field val 20; 


u32 parent, div; 


if( ‘elk -> clksel || !clk -> clksel_mask ) 
return — EINVAL; 





// 根 据 新 的 parent 获得 divisor 值 和 寄存 器 应 该 填写 的 值 
parent div 2. get. div and fieldval( new. parent, clk, &field val); 





if( ! parent, div) 
return — EINVAL; 
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// 写 寄存 器 并 重建 parent 的 链表 
_write_clksel_reg( clk, field. val) ; 


clk_reparent( clk, new. parent) ; 


/重新 设置 clk 的 频率 
/ * CLKSEL clocks follow their parents rates, divided by a divisor * / 


clk —> rate = new_parent —> rate; 


if( parent, div >0) 
clk —> rate/ = parent. div; 


pr. debug( "clock; 96s; set parent to 96 s( new rate ?61d) Wn" , 


clk -> name, clk -> parent -> name, clk -> rate) ; 


return 0; 


// 根 据 需 要 设 定 的 clock 频率 找到 相应 的 divisor 值 , 返 回 rounded clock rate 或 者 -1 error 
//divisor 值 通过 传 址 方式 返回 
u32 omap2_clksel_round_rate_div(struct clk * clk, unsigned long target, rate, 


u32 * new, div) 


unsigned long test, rate ; 

const struct clksel * clks; 
const struct clksel rate * clkr; 
u32 last, div 20; 


if( ‘elk -> clksel || !clk -> clksel_mask ) 


return ~ 0; 


pr debug(" clock; clksel_round_rate_div; 96s target rate % ld\n" , 


clk -> name, target, rate) ; 
* new_div = 1; 


// 首 先 根据 现在 的 clock parent 获得 相应 的 clk_sel 
clks =_get_clksel_by_parent( clk, clk -> parent) ; 
if( Y elks) 


return ~ 0; 





// 根 据 clk_sel 的 divisor 值 来 计算 rate 是 否 能 round target rate 
for( clkr = clks —> rates; clkr —>div; clkr ++ ) f 
if( !(clkr —> flags & cpu, mask) ) 
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continue ; 


/ * Sanity check */ 
if( clkr -> div <= last. div) 
pr err(" clock; clksel rate table not sorted " 


"for clock 96s" , clk -> name) ; 


last. div = clkr -> div; 


// 根 据 parent 的 rate 和 divisor 值 来 计算 相应 的 clock 的 rate 


test, rate = clk -> parent -> rate/clkr -> div; 


// 如 果 rate <= 目标 rate 即 是 找到 了 round target rate 
if( test, rate <= target, rate) 
break;/ * found it */ 


if( !elkr —> div) | 
pr err(" clock; Could not find divisor for target " 
"rate % ld for clock 96s parent 96s Wn" , target. rate, 
clk -> name, clk -> parent -> name) ; 


return ~ 0; 


// 传 址 返回 divisor 值 


* new_div = clkr —> div; 


pr_debug( "clock: new, div = 96d, new rate = %ld\n", * new, div, 


(clk -> parent -> rate/clkr -> div) ) ; 


// 3E [B] clock 修改 divisor 值 后 的 rate 值 
return clk -> parent -> rate/clkr -> div; 


// 根 据 clock 和 target rate 查找 rounded rate , divider 数组 必须 从 低 到 高 排序 


long omap2_clksel_round_rate( struct clk * clk, unsigned long target, rate ) 


| 


u32 new_div; 





return omap2_clksel_round_rate_div(clk, target rate, &new_div) ; 
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DPLL 锁 相 环 时 钟 会 和 芯片 中 究竟 采用 怎样 的 锁 相 环 技术 相关 。DM 3730 中 使 用 的 DPLL 
结构 如 图 4-47 所 示 。 图 4-47 引 自 《DM 3730 芯片 手册 》 中 第 299 页 框图 。 
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Al 4-47 DM 3730 DPLL 结构 图 


HIA 4-47 可 见 ，DM 3730 AY DPLL 主要 是 设置 乘 数 和 除数 (M 和 N)， 另 外 DPLL 有 
bypass 模式 。 操 作 接 口 分 析 如 下 : 


//DPLL 的 set, rate 函数 接口 实现 ,根据 频率 可 设置 为 bypass 模式 或 者 
// 计 算 M 和 NN 的 值 后 写 DPLL 并 设置 为 lock mode 
// 调 用 该 函数 后 不 应 该 影响 相应 的 bypass clock 和 ref clock 的 引用 计数 和 状态 


int omap3_noncore_dpll_set_rate( struct clk * clk, unsigned long rate) 


| 





struct clk * new, parent = NULL; 
ul6 freqsel =0; 
struct dpll_data * dd; 


int ret; 





// 首 先 要 确认 是 DPLL 并 且 要 设置 rate 与 现在 DPLL rate 不 同 
if( ! elk | !rate ) 
return — EINVAL; 




















dd = clk -> dpll_data; 
if( !dd) 
return — EINVAL; 


if( rate == omap2_get_dpll_rate( clk) ) 


return 0; 


Pe 
* Ensure both the bypass and ref clocks are enabled prior to 


* doing anything; we need the bypass clock running to reprogram 


241 


* the DPLL. 

*/ 
// Bi 253€ enable bypass clock 和 ref clock , 由 于 重 编 DPLL 时 要 使 用 bypass clock 
omap2. clk enable( dd -> clk bypass) ; 
omap2_clk_enable( dd -> elk, ref) ; 






































// 如 果 设 置 rate 等 于 bypass rate, l| fi bypass 模式 
if( dd -> elk, bypass -> rate == rate && 
(clk -> dpll, data -> modes &(1 << DPLL LOW. POWER, BYPASS) ) ) } 


pr debug(" clock; 965; set rate; entering bypass. Wn" , clk -> name) ; 





ret = _omap3_noncore_dpll_bypass( clk) ; 
if( !ret) 
new. parent = dd -> clk. bypass; 
| else | 
// 需 要 设置 M 和 NN 为 lock 模式 ,首先 要 通过 omap2. dpll. round, rate 计算 出 M 和 NN 的 值 
if( dd —> last, rounded, rate | = rate) 





























omap2. dpll round, rate( clk, rate) ; 





// 如 果 不 能 准确 获得 要 设置 的 rate 则 返回 错误 
if( dd —> last, rounded. rate ==0) 
return — EINVAL; 


/ * No freqsel on OMAP4 and OMAP3630 * / 
/人 /只 有 omap4 才 需 要 计算 并 设置 freqsel 
if( !cpu_is_omap44xx() && !cpu_is_omap3630() ) | 
freqsel 2. omap3, dpll. compute. freqsel( clk, dd —> last, rounded n); 
if( !freqsel) 
WARN ON(1); 





pr debug(" clock; 965; set rate; locking rate to % lu. Vn" , 


clk —» name, rate) ; 


// 设 置 M 和 NN 并 设置 lock 模式 
ret = omap3_noncore_dpll_program( clk, dd -> last rounded, m, 


dd -> last, rounded n, freqsel) ; 


// 记 录 新 的 parent, 后 面 会 重新 设置 parent 
if( lret) 
new. parent = dd -> clk ref; 








242 


if( Iret) | 
// 至 此 已 经 准确 设置 rate 
/* 


* Switch the parent clock in the hierarchy, and make sure 


























* that the new parent s usecount is correct. Note: we 

* enable the new parent before disabling the old to avoid 

* any unnecessary hardware disable -> enable transitions. 

*/ 
// 28 WE clk 有 了 新 的 parent ( 很 大 可 能 没有 变化 ) ,需要 将 old parent disable 
// 为 了 避免 同一 个 parent clk 不 必要 的 disable -> enable 流程 ,在 此 先 enable 
if( clk -> usecount) | 








omap2_clk_enable( new. parent) ; 


omap2 clk disable( clk -> parent) ; 


// 重 新 设置 parent 和 rate 
clk reparent(clk, new. parent) ; 


clk —> rate = rate; 


// 调 用 该 图 数 后 不 应 该 影响 相应 的 bypass clock 和 ref clock 的 引用 计数 和 状态 ,之 前 已 经 
// enable ,所 以 要 disable ,保证 调用 此 函数 clk 的 状态 没有 变化 . 

omap2_clk_disable( dd -> clk_ref) ; 

omap2_clk_disable( dd -> clk bypass) ; 


return 0; 
// VE DPLL 的 rate 入 口 函数 ,负责 计算 出 相应 的 M 和 N, 最 后 的 M 和 NN 值 会 记录 在 clk 中 的 dpll_data 中 


long omap2_dpll_round_rate( struct clk * clk, unsigned long target, rate) 


| 





int m, n, r, e, scaled max m; 
unsigned long scaled rt rp, new, rate; 
int min e= -1, min e m= -1, mine n= -1; 


struct dpll, data * dd; 


if( lclk || !clk -> dpll. data) 
return ~ 0; 


dd = clk -> dpll_data; 


pr. debug( "clock; starting DPLL round. rate for clock %s, target rate 
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"%\d\n" , clk -> name, target. rate) ; 


//scaled_rt_rp 应 该 为 rate target 和 rate parent 

// 首 先 通过 因子 把 multipy 放大 ,通过 因 式 运算 最 终 应 该 就 是 target. rate 
scaled, rt. rp = target, rate/( dd —» clk_ref -> rate/DPLL SCALE. FACTOR) ; 
scaled max m = dd -> max, multiplier * DPLL SCALE FACTOR ; 
































dd —> last. rounded, rate 20; 


人/ 开始 测试 合适 的 M 和 N 
for( n = dd -> min, divider; n <= dd -> max_divider; n ++ ) | 


/ * Is the(input clk, divider) pair valid for the DPLL? */ 
// 如 果 NN 导致 内 部 Fint 无 效 , 则 跳 过 ;如 果 N 已 经 导致 内 部 rate 太 小 ,说 明 找 不 到 合适 的 N 
r- dpll test fint(clk, n) ; 
if( r == DPLL FINT UNDERFLOW ) 
break ; 
else if(r == DPLL FINT INVALID) 








continue ; 


/ * Compute the scaled DPLL multiplier, based on the divider */ 
基于 N 来 计算 乘 数 ,同样 要 放大 . 


m =scaled_rt_rp * n; 





fe 
* Since wé re counting n up, a m overflow means we 
* can bail out completely( since as n increases in 
* the next iteration, theré s no way that m can 
* increase beyond the current m) 
*/ 
if( m > scaled. max, m) 


break ; 


r- dpll test mult( &n, n, &new, rate, target, rate, 


dd -> elk, ref -> rate) ; 


/ * m can t be set low enough for this n - try with a larger n */ 
if( r == DPLL MULT UNDERFLOW) 


continue ; 


// 计 算 误差 


e = target_rate — new_rate; 
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pr_debug( "clock: n 2 96d; m=%d; rate error is 96 d " 


" (new. rate = 96ld) n" , n, m, e, new rate) ; 


if(min_e == -1 | 
min, e >= (int) (abs(e) -dd —>rate_tolerance) ) | 
min_e =e; 
min_e_m=m; 


min_e_n=n; 


// 找 到 目前 最 好 的 M 和 N 的 值 


pr. debug( " clock; found new least error % d\n" , min e) ; 


/ * We found good settings —— bail out now * / 
// 如 果 可 以 接受 , 则 跳出 ,最 新 的 值 记录 在 min. e. m 和 min, e. n 中 
if( min, e <= dd —> rate, tolerance) 


break ; 





if( min, e «0) | 
pr. debug( " clock; error; target rate or tolerance too low Wn" ) ; 


return ~ 0; 


// 找 到 相应 的 M 和 NN 记录 在 dpll_data 中 


dd —> last. rounded. m = min, e m; 





dd —> last, rounded. n = min e n; 








dd —» last. rounded, rate = | dpll compute. new. rate( dd -> clk ref -> rate, 


min e m, min e n); 


pr. debug( " clock; final least error; e 2 96d, m=%d, n=%d\n", 





min e, min e m, min e n); 





pr debug(" clock; final rate; ?6ld (target rate: %ld) Wn" , 


dd -> last. rounded. rate, target, rate) ; 


return dd -> last, rounded, rate; 


4. 时 钟 管理 初始 化 
实际 的 芯片 中 所 有 时 钟 的 信息 都 在 clockxxxx_data.c AY, DM 3730 的 时 钟 信 息 是 在 
clock3xxx_data c 内 ， 其 中 不 仅 包含 了 详细 的 时 钟 信息 ， 还 包含 芯片 相关 的 时 钟 管理 初始 化 
操作 。 详 细 分 析 如 下 : 
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// KRGE omap3 chip 的 整个 clock tree 的 初始 化 ,包括 clock 数据 结构 的 初始 化 和 clock tree 的 





// f$ 


E. ,并 且 enable 那些 需要 在 init 阶段 使 能 的 clock。 它 是 omap 架构 中 重要 的 初始 化 函数 


int — init omap3xxx_clk_init( void) 


| 


struct omap. clk * c; 


u32 cpu, clkflg 20; 


if( cpu, is, omap3517( ) ) | 
cpu mask = RATE IN 34XX; 
cpu. clkflg = CK 3517; 
| else if( cpu. is; omap3505( ) ) | 
cpu, mask = RATE IN. 34XX ; 
cpu. clkflg = CK. 3505; 
| else if( cpu. is; omap3630( ) ) | 
cpu, mask = (RATE IN 34XX | RATE IN 36XX); 
cpu. clkflg = CK. 36XX ; 
| else if( cpu. is. omap34xx( ) ) | 
if( omap. rev( ) == OMAP3430. REV. ESI. 0) | 
cpu, mask = RATE IN, 3430ESI ; 
cpu. clkflg = CK. 3430ESI ; 
| else | 
/ok 
* Assume that anything that we haven t matched yet 
* has 3430ES2 - type clocks. 
*/ 
cpu, mask = RATE IN, 3430ES2PLUS; 
cpu. clkflg = CK_3430ES2PLUS ; 
| 
} else | 


WARN(1, "clock; could not identify OMAP3 variant Wn" ) ; 
if( omap3. has. 192mhz clk( ) ) 
omap. 96m. alwon. fck = omap. 96m alwon. fck 3630; 


if( cpu, is; omap3630( ) ) | 
J * 


* 


XXX This type of dynamic rewriting of the clock tree is 


* deprecated and should be revised soon. 


* 


For 3630; override clkops omap2. dflt, wait for the 
clocks affected from PWRDN reset Limitation 


* 


*/ 

// 对 于 omap3630 需要 调整 相应 的 操作 函数 

dpll3_m3x2_ck. ops = 
&clkops_omap36xx_pwrdn_with_hsdiv_wait_restore ; 

dpll4_m2x2_ck. ops = 
&clkops_omap36xx_pwrdn_with_hsdiv_wait_restore ; 

dpll4_m3x2_ck. ops = 
&clkops_omap36xx_pwrdn_with_hsdiv_wait_restore ; 

dpll4_m4x2_ck. ops = 











&clkops_omap36xx_pwrdn_with_hsdiv_wait_restore ; 
dpll4_m5x2_ck. ops = 








&clkops_omap36xx_pwrdn_with_hsdiv_wait_restore ; 
dpll4_m6x2_ck. ops = 


&clkops_omap36xx_pwrdn_with_hsdiv_wait_restore ; 





J * 
* XXX This type of dynamic rewriting of the clock tree is 
* deprecated and should be revised soon. 
*/ 
if( epu, is; omap3630( ) ) 
dpll4 dd = dpll4 dd 3630; 
else 


dpll4. dd = dpll4 dd. 34xx; 




















// 1E] omap 系统 clock 驱动 注册 chip 相关 的 通用 上 层 操作 接口 


clk_init( &omap2. clk, functions) ; 





// 对 每 个 clock 进行 preinit 
for( c = omap3xxx_clks; c <omap3xxx_clks + ARRAY, SIZE( omap3xxx_clks) ; 


c++) 


clk_preinit(¢ —> lk. clk) ; 





// 将 每 个 clock 加 入 系统 管理 注册 ,并 将 clock 与 所 属 的 clock domain 绑 定 
for( c = omap3xxx_clks; c < omap3xxx_clks + ARRAY_SIZE( omap3xxx_clks) ; 


, 














c++) 
if( c -> epu & cpu_clkflg) | 
clkdev_add( &c -» 1k) ; 
clk register( c —> lk. clk) ; 
// 初 始 化 clock 将 clock 与 所 属 的 clock domain 4872 
omap2. init, clk clkdm( e -> lk. clk) ; 
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/根据 晶振 的 时 钟 遍历 所 有 的 时 钟 并 计算 频率 


recalculate, root, clocks( ) ; 


pr. info( " Clocking rate( Crystal/Core/ MPU) : % ld. 96011d/961d/961d MHzWn" , 
(ose, sys. ck. rate/1000000) , ( ose. sys. ck. rate/100000) % 10, 
( core, ck. rate/1000000) , ( arm. fck. rate/1000000) ) ; 


/o 
* Only enable those clocks we will need, let the drivers 
* enable other clocks as necessary 
*/ 
// X] clock 进行 enable 操作 ,如 果 clock 标记 为 kernel init 时 enable 则 enable 该 clock 


clk. enable, init. clocks( ) ; 


/* 
* Lock DPLLS and put it in autoidle. 
*/ 
if( omap rev() >= OMAP3430 REV ES2 0) 
omap3, clk lock dpll5( ) ; 


/ * Avoid sleeping during omap3. core dpll m2, set, rate( ) * / 
sdre, ick p = clk get( NULL, "sdre ick" ) ; 
arm, fck p = clk get( NULL, "arm fck" ) ; 


return 0; 





注意 ， 该 操作 是 对 整个 系统 的 时 钟 的 初始 化 函数 ， 所 以 需要 在 系统 初始 化 比较 早 的 时 候 
进行 ， 对 于 DM 3730 是 在 板 级 的 中 断 初始 化 接口 中 调用 。 
至 此 ， 关 于 时 钟 管理 的 框架 和 主要 接口 分 析 完 毕 。 





4.7 时 间 管 理 ( Time) 


4.7.1 时 间 管 理 基 本 需求 


时 间 管 理 是 操作 系统 实现 的 一 个 基本 方面 ， 在 操作 系统 中 对 于 时 间 管 理 的 需求 分 为 疗 干 
不 同 的 类 别 ; 




















e time keeping 计时 。 

* clock synchronization 时 钟 同步 。 

e time-of- day representation (TOD) 一 一 时 间 日 期 表示 。 
* next event interrupt scheduling 下 一 个 事件 中 断 调度 。 
* process and in— kernel timers 进程 和 内 核定 时 器 。 

* process accounting 进程 调度 记录 。 
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* process profiling 进程 分 析 。 
除了 以 上 功能 的 需求 还 对 时 间 精 度 有 需求 ， 需 要 能 够 支持 各 种 时 间 精 度 的 设备 。 


4.7.2 ”时间 管理 框架 介绍 


1. 老 版 本 内 核 时 间 管 理 框架 

在 Linux 2. 6. 16 之 前 ， 内 核 一 直 使 用 一 种 称 为 timer wheel 的 机 制 来 管理 时 钟 。 这 就 是 
熟知 的 基于 Hz 的 timer 机 制 。timer wheel 有 占用 的 内 存 少 等 优点 ， 但 timer wheel 的 实现 机 制 
仍然 存在 弊端 。 一 方面 timer wheel 是 为 timeout 类 型 的 定时 器 优化 的 ， 并 不 适合 精准 定时 
timer; 男 一 方面 ， 由 于 timer wheel 是 建立 在 Hz 的 基础 上 的 ， 因 此 其 计时 精度 无 法 进一步 提 
高 。 毕 竟 一 味 的 通过 提高 Hz 值 来 提高 计时 精度 并 无 意义 ,结果 只 能 是 产生 大 量 的 定时 中 
断 ， 增 加 额外 的 系统 开销 。 因 此 ， 有 必要 将 高 精度 的 timer 与 低 精度 的 timer 分 开 ， 这 样 既 
可 以 确保 低 精度 的 timeout 类 型 的 定时 器 应 用 ， 也 便于 高 精度 的 timer 类 型 定时 器 的 应 用 。 
另外 timer wheel 的 实现 与 jiffies 的 耦合 性 太 强 ， 非常 不 便于 扩展 。 

2. 新 的 时 间 管 理 框架 

为 了 解决 timer wheel 低 精 度 以 及 与 内 核 其 他 模块 的 高 耦合 性 的 缺点 ，Linux 内 核 引 入 了 
hrtimer。 另 外 为 了 能 在 电源 管理 方面 进行 优化 ， 有 必要 去 除 以 频率 (Hz) 触发 的 定时 时 钟 
中 断 ， 改 为 动态 时 钟 机 制 (dynamic tick) 或 者 说 NO. HZ 机 制 。 新 的 时 间 管 理 框架 如 
图 4-48 所 示 。 

下 面 介绍 其 中 的 各 个 模块 。 

CD 时 钟 源 设 备 (clock-source device) 。 它 是 系统 中 可 以 提供 一 定 精度 的 计时 设备 。 不 
同 的 时 钟 源 提供 的 时 钟 精度 是 不 一 样 的 。 此 外 ， 时 钟 源 的 计时 都 是 单调 递增 的 ( monotoni- 
cally) 。 时 钟 源 作为 系统 时 钟 的 提供 者 ， 在 可 靠 并 且 可 用 的 前 提 下 精度 越 高 越 好 。 在 Linux 
中 不 同 的 时 钟 源 有 不 同 的 频率 ， 具 有 更 高 频率 的 时 钟 源 会 优先 被 系统 使 用 。 

D 时 钟 事件 设 备 (clock-event device) 。 它 是 系统 中 可 以 触发 one-shot ( 单 次 ) 或 者 周 
期 性 中 断 的 设备 。 某 些 设备 既 可 以 做 时 钟 源 设备 也 可 以 做 时 钟 事件 设备 。 时 钟 事件 设备 的 类 
型 分 为 全 局 和 per-cpu 两 种 类 型 。 全 局 的 时 钟 事件 设备 完成 的 是 系统 相关 的 工作 ， 例 如 完成 
系统 的 tick 更 新 ; per-cpu 的 时 钟 事件 设备 主要 完成 本 地 CPU 上 的 一 些 功能 ， 例 如 对 在 当前 
CPU 上 运行 进程 的 时 间 统计 ，profile， 设 置 本 地 CPU 上 的 下 一 次 事件 中 断 等。 和 时 钟 源 设备 
的 实现 类 似 ， 时 钟 事件 设备 也 通过 频率 来 区 分 优先 级 关系 。 

(9 tick device。 它 是 用 来 处 理 周期 性 的 tick event, tick device 其 实 是 对 时 钟 事件 设备 的 
整合 ， 因 此 tick device 也 有 one-shot 和 周期 性 这 两 种 中 断 触 发 模式 。 每 注册 一 个 时 钟 事件 
设备 ， 这 个 设备 会 自动 被 注册 为 一 个 tick device。 全 局 的 tick device 用 来 更 新 诸如 jiffies 这 
样 的 全 局 信息 ，per-cpu 的 tick device 则 用 来 更 新 每 个 CPU 相关 的 特定 信息 。 

@ hrtimer。 它 是 建立 在 per-cpu 时 钟 事件 设备 基础 上 的 。 对 于 一 个 SMP 系统 ， 如 果 只 
有 全 局 的 时 钟 事件 设备 ，hrtimer 无 法 工作 。ktime_t 是 hrtimer 主要 使 用 的 时 间 结 构 。 无 论 使 
用 哪 种 体系 结构 ，ktime_t 始终 保持 64bit 的 精度 ， 并 且 考 虑 了 大 小 端的 影响 。hrtimer 有 两 种 
工作 模式 : 低 精 度 模 式 (low resolution mode) 与 高 精度 模式 (high - resolution mode), 
然 hrtimer 子 系统 是 为 高 精度 的 timer 准备 的 ， 但 是 系统 可 能 在 运行 过 程 中 动态 切换 到 不 同 精 
度 的 时 钟 源 设备 ， 因 此 hrtimer 需要 能 够 在 低 精度 模式 与 高 精度 模式 下 自由 切换 。 低 精度 模 
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式 是 建立 在 高 精度 模式 基础 之 上 的 ， 在 低 精 度 模式 下 ，hrtimer 的 核心 处 理 函 数 是 hrtimer_ 
run_queues， 每 一 次 tick 中 断 都 要 执行 一 次 。hrtimer_bases 是 实现 hrtimer 的 核心 数据 结构 , 











通过 hrtimer bases, hrtimer 可 以 管理 挂 在 每 一 个 CPU 上 的 所 有 timer, TE update, process. 


times 中 ， 除 了 处 理 处 于 低 精 度 模式 的 hrtimer 外 ， 还 要 唤醒 时 间 中 断 的 softirg (TIMER _ 
SOFTIRQ) 以 便 执行 timer wheel 的 代码 。 由 于 hrtimer 子 系统 的 加 入 ， 在 时 间 中 断 的 softirg 
中 还 需要 通过 hrtimer_run_pending 检查 是 否 可 以 将 hrtimer 切换 到 高 精度 模式 ; 如 果 可 以 将 
hrtimer 切换 到 高 精度 模式 ， 则 调用 hrtimer_switch_to_hres ph BGT WA, 

©) dynamic tick。 它 能 在 系统 空闲 时 通过 停止 tick 的 运行 以 达到 降低 处 理 器 功 耗 的 目的 。 
使 用 dynamic tick 的 系统 ， 只 有 在 实际 工作 时 才 会 产生 tick, BU tick 处 于 停止 状态 。 
dynamic tick 是 为 彻底 替换 掉 周 期 性 的 tick 机 制 而 产生 的 。 它 对 周期 性 运行 的 tick 机 制 所 完 











成 的 (如 进程 时 间 片 的 计算 、 更 新 profile、 协 助 CPU 进行 负载 























的 衡 等 ) 诸多 工作 都 提供 








Ep 


相应 的 模拟 机 制 。hrtimer 从 低 精 度 模式 切换 到 高 精度 模式 的 切换 点 ， 也 是 低 精 度 模式 下 从 
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周期 性 tick 到 dynamic tick 的 切换 点 ， 会 将 tick 切换 到 one-shot 模式 下 ， 另 外 通过 tick_nohz_ 
handler 模拟 周期 性 tick device 完成 的 工作 : 如 果 当 前 CPU 负责 全 局 tick device 的 工作 ， 则 更 
新 jiffies， 同 时 完成 对 本 地 CPU 的 进程 时 间 统 计 等 工作 ; 如 果 当 前 tick device 在 此 之 前 已 经 
处 于 停止 状态 ， 为 了 防止 tick 停止 时 间 过 长 造成 watchdog 超时 ， 从 而 引发 soft - lockdep 的 
错误 ， 需 要 通过 调用 touch_softlockup_watchdog 软件 复位 看 门 狗 防 止 其 溢出 ; 设置 了 下 一 次 
的 超时 事件 ， 但 是 由 于 系统 空闲 时 会 停止 tck， 因 此 下 一 次 的 超时 事件 可 能 发 生 ， 也 可 能 不 
发 生 。 在 高 精度 模式 下 tick_sched_timer 用 来 模拟 周期 性 tick device 的 功能 。dynamic tick 的 
实现 也 使 用 了 这 个 函数 。 这 是 因为 hrtimer 在 高 精度 模式 时 必须 使 用 one - shot 模式 的 tick 
device， 这 也 同时 符合 dynamic tick 的 要 求 。 虽 然 使 用 同样 的 函数 ， 表 面 上 都 会 触发 周期 性 
的 tick 中 断 ， 但 是 使 用 dynamic tick 的 系统 在 空 闪 时 会 停止 tick 工作 ， 因 此 tick 中 断 不 会 是 
周期 产生 的 。 对 于 tick 的 开关 在 cpu idle 中 通过 tick_nohz_stop_sched_tick 和 tick_nohz_restart 
_sched_tick 来 实现 ， 其 中 通过 tick_do_update_jiffies64 来 更 新 时 间 ， 保 证 模拟 的 正确 性 。 


4.7.3 TI 芯片 时 间 管 理 相关 实现 详解 


关于 时 间 管 理 ，Linux 内 核 已 经 提供 了 完整 的 解决 方案 ， 世 片 本 身 的 实现 主要 是 clock 
event 和 clock source 的 便 件 实现 。 下 面 基 于 DM 3730 分 析 一 下 相关 的 实现 。 

1. clock event 相关 实现 

clock event 的 相关 实现 如 下 : 




















// 系 统 clock event 的 初始 化 接口 
static void __ init omap2_gp_clockevent_init( void) 
| 

u32 tick_rate; 


int sre; 
inited =1; 


// 申 请 特定 的 gp timer 

gptimer = omap_dm_timer_request_specific( gptimer_id) ; 
BUG_ON( gptimer == NULL) ; 

// 同 样 的 gp timer 作为 pm debug 的 wakeup 定时 timer 


gptimer_wakeup = gptimer; 





// 指 定 clock event 的 source clock 
#if defined( CONFIG_OMAP_32K_TIMER) 
src = OMAP TIMER, SRC 32 KHZ; 
#else 
sre = OMAP_TIMER_SRC_SYS_CLK; 
WARN( gptimer_id == 12, "WARNING: GPTIMERI2 can only use the " 


"secure 32KiHz clock source\n" ) ; 





#endif 
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// 设 置 gp timer 的 source clock 
if( gptimer id ! = 12) 
WARN(IS ERR, VALUE( omap. dm. timer. set, source( gptimer, src) ) , 


"timer — gp; omap. dm timer, set, source( )failed Wn" ) ; 


// 获 得 vate 


tick rate = clk get rate( omap. dm timer. get, fclk( gptimer) ) ; 


pr. info( " OMAP clockevent source; GPTIMER% d at 96 u HzWn" , 


gptimer id, tick rate) ; 


// 设 置 irq 及 enable overflow 模式 ,真正 的 gp timer start 是 在 set. mode 的 时 候 执行 


omap2 gp. timer irq. dev, id = (void * ) gptimer; 
setup. irq( omap. dm. timer get, irq( gptimer) , &omap2. gp. timer, irq) ; 
omap. dm. timer. set, int enable( gptimer, OMAP TIMER. INT OVERFLOW) ; 





























// RE clock event 精度 的 属性 ,通常 是 one. shot 的 时 钟 设 置 next event 时 使 用 的 ， 
// 何 配置 时 钟 ,对 于 周期 性 时 钟 没 有 进行 这 些 计算 
clockevent_gpt. mult = div. sc(tick rate, NSEC_PER_SEC, 

















clockevent_gpt. shift) ; 
clockevent_gpt. max_delta_ns = 
clockevent_delta2ns ( Oxffffffff, &clockevent_gpt) ; 
clockevent_gpt. min_delta_ns = 
clockevent_delta2ns(3 , &clockevent_gpt) ; 


/ * Timer internal resynch latency. * / 


// 注 册 相 应 的 clock event 
clockevent_gpt. cpumask = cpumask_of(0); 


clockevents_register_device( &clockevent_gpt) ; 


// 对 于 kernel 的 clock event, 主要 是 做 iick 的 源 . 
// TE event, device add 的 时 候 会 通知 tick 管理 
//event。 在 时 钟 中 断 中 通 
// 续 的 tick 及 timer 的 处 理 


static struct clock_event_device clockevent_gpt = | 


























. name =" gp timer", 
. features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT, 
. shift =32, 





. set_next_event = omap2_gp_timer_set_next_event, 


. set mode = omap2_gp_timer_set_mode , 














HORE aN 


E 层 ,然后 设置 周期 方式 ,进而 以 一 定 周期 发 起 时 钟 
过 tick 层 注 册 的 event. handler 3E [8] tick 层 发 布 时 钟 时 间 , 从 而 完成 后 


E 











// 设 置 timer 的 next event 的 接口 


static int omap2_gp_timer _set_next_event( unsigned long cycles, 

















struct clock_event_device * evt) 


// 设 置 event 的 时 间 并 且 start 时 钟 
omap. dm, timer, set, load, start( gptimer, 0, Oxffffffff — cycles) ; 





return 0; 


| 

















// 设 置 mode 的 接口 ,这 里 实际 为 tick 源 ,所 以 主要 是 CLOCK_EVT_MODE_PERIODIC 


static void omap2_gp_timer_set_mode( enum clock_event_mode mode, 














struct clock_event_device * evt) 
u32 period; 
omap. dm. timer. stop( gptimer) ; 
switch ( mode) | 
case CLOCK. EVT MODE PERIODIC: 


// 设 置 周期 值 , 即 1s 的 tick 数 换算 的 timer 的 加 载 值 
period = clk_get_rate( omap_dm_timer_get_fclk( gptimer) ) /HZ; 

















period — =1; 
// Et timer 的 计数 值 并 且 保 证 是 autoload 方式 可 以 周期 性 触发 中 断 
omap_dm_timer_set_load_start( gptimer, 1, Oxffffffff — period) ; 
break ; 
case CLOCK_EVT_MODE_ONESHOT; 
// 不 需要 设置 
break ; 
case CLOCK, EVT MODE UNUSED: 
case CLOCK. EVT MODE SHUTDOWN: 
case CLOCK. EVT MODE RESUME: 
break ; 





2. clock source 相关 实现 
clock source 的 相关 实现 如 下 : 








//clock source 的 初始 化 ,主要 是 对 属性 的 设置 ,并 注册 clock source 


static void __ init omap2_gp_clocksource_init( void) 











253 


static struct omap_dm_timer * gpt; 

u32 tick_rate; 

static char errl[ ] ^ initdata = KERN, ERR 
"668: failed to request dm — timer Yn" ; 

static char err2[ ] ^ initdata = KERN, ERR 


"O68: can t register clocksource ! Wn" ; 


// 获 得 gp timer 
gpt = omap. dm, timer request( ) ; 
if( !gpt) 
printk( errl , clocksource_gpt. name) ; 


gpt. clocksource = gpt; 


// 设 置 sys_clk 为 其 source 
omap_dm_timer_set_source( gpt, OMAP_TIMER_SRC_SYS_CLK) ; 
// 获 得 sys_clk rate 以 便 后 面 计 算 相 应 属性 


tick rate = clk_get_rate( omap_dm_timer_get_fclk( gpt) ) ; 











W 


// 从 0 计数 ,并 start gp timer 


omap. dm. timer. set. load. start(gpt, 1, 0) ; 





l 











// 计 算 mult 属性 


clocksource_gpt. mult = 


ul 


clocksource khz2mult( tick rate/1000 , clocksource_gpt. shift) ; 
// 注 册 clock source 
if( clocksource_register( &clocksource_gpt) ) 


printk(err2 , clocksource_gpt. name) ; 





//clock source 的 属性 


static struct clocksource clocksource, gpt = | 





. name =" gp timer", 

. rating =300, 

.read = clocksource_read_cycles, 

. mask = CLOCKSOURCE_MASK (32), 

. shift =24， 

. flags = CLOCK SOURCE IS CONTINUOUS, 


E 


// 查 询 clock source 的 计数 ,使 用 gp timer 的 时 候 是 从 0 计数 ,所 以 可 以 很 久 才 overflow 


static cycle t clocksource_read_cycles( struct clocksource * cs) 
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return( cycle t) omap_dm_timer_read_counter( gpt_clocksource ) ; 





| 


3. 初始 化 相关 实现 
整体 的 初始 化 是 通过 system timer 来 实现 的 ， 细 节 如 下 : 





//Linux kernel 第 一 个 注册 的 clock, event, device 将 作为 tick 源 周期 发 布 时 钟 中 断 
// 在 omap3 上 gptimerl 是 这 个 时 钟 ,作为 machine, desc 的 sys. timer ,初始 化 时 会 调用 其 init 
struct sys_timer omap_timer = | 

. init = omap2_gp_timer_init , 


E 
// VEJ machine, desc 的 sys, timer 的 初始 化 接 


static void __ init omap2_gp_timer_init( void) 
| 
#ifdef CONFIG_LOCAL_TIMERS 
if(cpu_is_omap44xx( ) ) | 
twd_base = ioremap( OMAP44XX_LOCAL_TWD_BASE, SZ_256) ; 
BUG. ON( !twd_hase) ; 





LE 


| 
#endif 
//omap 平台 的 dual mode timer 的 初始 化 在 plat - omap/dmtimer 中 


omap_dm_timer_init( ) ; 


//clock event 和 clock source 初始 化 ,如 果 是 32k 时 钟 作为 clock source 相关 的 初始 化 后 续 
// 作 为 arch_initcall 执行 . 

omap2. gp. clockevent init( ) ; 

omap2. gp. clocksource. init( ) ; 


| 


关于 Linux 内 核 时 间 管 理 ， 处 理 器 的 代码 只 要 实现 以 上 部 分 就 可 以 了 ， 其 余 的 部 分 都 是 
由 系统 统一 提供 并 实现 的 。 





4.8 通用 目的 输入 输出 (GPIO) 


GPIO 是 General Purpose Input/Output 的 缩写 ， 是 一 种 灵活 的 可 以 通过 软件 进行 控制 的 数 
字 信 号 接口 。 现 代 的 SoC 都 提供 GPIO, 已 经 成 为 SoC 一 个 强 有 力 的 扩展 工具 ， 可 以 通过 
GPIO 以 及 软件 实现 一 些 接口 功能 模块 ， 实 现 对 外 部 器 件 进行 控制 。 
4. 8.1 GPIO 管理 基本 需求 


GPIO 是 通过 芯片 管 脚 来 进行 操作 ， 可 以 作为 输入 也 可 以 作为 输出 ， 作 为 输入 的 时 候 还 
可 以 作为 中 断 源 。 
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GPIO 也 是 一 种 公共 资源 ， 所 以 需要 能 够 对 GPIO 进行 统一 的 管理 ， 能 够 申请 和 释放 ， 
还 可 以 配置 输入 或 者 输出 。 针 对 GPIO 作为 中 断 源 的 情况 ， 需 要 能 够 对 该 中 断 源 进行 管理 ， 
可 以 根据 需要 配置 成 边沿 触发 或 者 电 平 触 发 等 不 同 的 中 断 处 理 方式 。 


4.8.2 GPIO 管理 框架 介绍 





关于 GPIO 管理 ，Linux 内 核 提 供 了 GPIO lib 来 实现 具体 的 GPIO 服务 ， 提 供 了 统一 的 接 
口供 其 他 模块 使 用 ， 基 本 的 框架 如 图 4-49 所 示 。 




















GPIO client drivers 
Keypad driver Touch screen driver Ethernet driver 
De-muxed interrupt(4) GPIO interrupt de-mux(3) GPIO Pin configuration 














Linux interrupt handling subsystem GPIO lib | 
| | 
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OMAP 











图 4-49 Linux 内 核 GPIO 框架 














从 图 4-49 可 见 ， 各 种 设备 模块 都 可 以 访问 使 用 GPIO0， 相 应 的 需要 通过 GPIO lib 和 
Linux 内 核 中 断 处 理子 系统 进行 操作 。 而 真正 的 GPIO 芯片 的 实现 是 通过 GPIO chip 提供 的 接 
口 来 实现 的 。 

1. 外 部 使 用 GPIO 的 操作 接口 

GPIO lib 提供 的 功能 接口 如 下 : 











// XT GPIO 请 求 和 释放 的 接口 

extern int gpio. request( unsigned gpio, const char * label); 
extern void gpio_free( unsigned gpio) ; 

人/ 设置 GPIO 引 脚 输入 输出 状态 


extern int gpio_direction_input( unsigned gpio ; 























extern int gpio_direction_output( unsigned gpio, int value) ; 
// 由 于 GPIO 信号 可 能 出 现 抖动 该 接口 设置 去 拌 功 能 


extern int gpio_set_debounce( unsigned gpio, unsigned debounce) ; 
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// 获 得 和 设置 GPIO 引 脚 可 以 sleep 


extern int gpio_get_value_cansleep( unsigned gpio) ; 


extern void gpio_set_value_cansleep( unsigned gpio, int value) ; 


/ * A platform s < asm/gpio. h > code may want to inline the I/O calls when 


* the GPIO is constant and refers to some always — present controller, 


* giving direct access to chip registers and tight bitbanging loops. 


*/ 
// 3X45 GPIO 引 脚 的 值 
extern int gpio_get_value(unsigned gpio) ; 
/设置 GPIO 引 脚 的 值 
extern void gpio_set_value(unsigned gpio, int value) ; 
// 检 查 GPIO 是 否 可 以 sleep 
extern int gpio_cansleep(unsigned gpio ; 


// GPIO 号 转换 成 中 断 号 


extern int — gpio to irq( unsigned gpio ; 


























这 些 接口 的 名 字 都 很 好 理解 ， 相 应 的 都 会 调用 GPIO chip 的 接口 函数 。 
2. GPIO 内 部 管理 框架 
GPIO 框架 的 重要 数据 结构 就 是 gpio_chip ， 详 细 内 容 如 下 : 








struct gpio_chip | 


const char * label; 

struct device * dev; 

struct module * owner; 

int ( ** request) (struct gpio chip * chip, 


unsigned offset) ; 


void ( * free) (struct gpio. chip * chip, 
unsigned offset) ; 

int ( ** direction. input) (struct gpio chip * chip, 
unsigned offset) ; 

int ( * get) (struct gpio. chip * chip, 
unsigned offset) ; 

int ( ** direction. output) (struct gpio. chip * chip, 
unsigned offset, int value) ; 

int ( * set. debounce) (struct gpio. chip * chip, 
unsigned offset, unsigned debounce) ; 

void ( * set) (struct gpio chip * chip, 


unsigned offset, int value) ; 
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int ( * to_irq) (struct gpio_chip * chip, 


unsigned offset) ; 


void ( * dbg_show) (struct seq_file *s, 
struct gpio_chip * chip) ; 
// 管 理 GPIO 的 起 始 号 





int base; 

// 一 共管 理 GPIO 的 数目 

ul6 ngpio; 

const char * const * names; 
unsigned can sleep:1; 


unsigned exported :1 ; 


JE 





系统 中 可 以 有 多 个 gpio, chip, ， 而 每 个 gpio_chip 管理 一 组 GPIO, ， 其 中 base 表示 相应 的 


gpio_chip 管理 的 系统 中 的 起 始 GPIO 号 ， 一 共管 理 ngpio 个 GPIO, 


内 核 将 所 有 的 GPIO 组 成 数组 ， 每 个 GPIO 用 gpio_desc 进行 描述 ， 具 体 的 结构 如 下 : 


struct gpio_desc | 

struct gpio_chip * chip; 

unsigned longflags ; 
/ * flag symbols are bit numbers * / 
#define FLAG_REQUESTED 0 
#define FLAG_IS_OUT 1 
#define FLAG_RESERVED 2 
#define FLAG_EXPORT 3 / * protected by sysfs_lock */ 
#define FLAG_SYSFS 4 /* exported via/sys/class/gpio/control * / 
#define FLAG_TRIG_FALL 5 / * trigger on falling edge * / 
#define FLAG_TRIG_RISE 6 / * trigger on rising edge * / 
#define FLAG_ACTIVE_LOW 7 / * sysfs value has active low * / 


#define ID_SHIFT 16 / * add new flags before this one * / 


#define GPIO FLAGS MASK — ((1««ID SHIFT) - 1) 
#define GPIO. TRIGGER, MASK( BIT( FLAG, TRIG, FALL) | BIT( FLAG, TRIG, RISE) ) 


#ifdef CONFIG. DEBUG. FS 
const char * label ; 

#endif 

E 


其 中 的 chip 表示 该 GPIO 由 哪个 gpio_chip 进行 管理 。 其 中 ，flags 表示 该 GPIO 是 否 被 请 





求 、 输 入 输出 状态 等 与 CPIO 功能 相关 的 状态 及 属性 。 
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GPIO 框架 中 还 需要 对 gpio_chip 进行 管理 ， 主 要 是 将 实际 的 物理 GPIO 的 管理 实体 gpio_ 


chip 和 逻辑 层 的 gpio_desc 进行 绑 定 ， 相 应 绑 定 的 GPIO 号 是 在 gpio_chip 的 base 至 base + ng- 
pio 之 间 。 对 之 前 gpio_request 申请 的 ， 只 有 在 绑 定 gpio_chip 之 后 才能 申请 成 功 ， 继 而 对 
GPIO 进行 正确 的 操作 。 

具体 的 gpio_chip 管理 接口 如 下 : 


// 加 入 gpio_chip 并 将 其 和 所 管理 的 gpio_dese 进行 绑 定 
extern int gpiochip_add(struct gpio_chip * chip) ; 
// 移 除 gpio. chip 并 对 gpio_dese 进行 合适 的 操作 移 除 绑 定 


extern int ”must_check gpiochip_remove( struct gpio_chip * chip); 


3. GPIO 的 sysfs 接口 

针对 应 用 程序 对 GPIO 操作 的 需求 ，GPIO 库 将 GPIO 开放 到 sysfs 文件 系统 中 ， 这 样 可 以 
在 用 户 层 对 GPIO 进行 相应 的 操作 。 在 用 户 层 进 行 操 作 的 好 处 是 ， 可 以 直接 进行 开发 而 不 是 
通过 驱动 程序 进行 ， 另 外 从 软件 版 权 考 虑 可 以 将 不 同 的 版 权 更 好 的 隔离 避免 彼此 的 污染 。 相 
应 的 接口 如 下 : 











// 将 GPIO 输出 给 sysfs 以 供用 户 层 使 用 
extern int gpio_export( unsigned gpio, bool direction_may_change) ; 
// 关 闭 GPIO 在 sysfs 的 接口 


extern void gpio_unexport( unsigned gpio ) ; 








开放 到 sysfs 的 GPIO 有 如 下 的 操作 接口 : 


J * 
* /sys/ class/gpio/gpioN. .. only for GPIOs that are exported 


*  /direction 


* * MAY BE OMITTED if kernel won t allow direction changes 
* * is read/write as "in" or "out" 

* * may also be written as "high" or "low" , initializing 

* output value as specified( " out" implies "low" ) 

*  /value 

* * always readable, subject to hardware behavior 

* * may be writable, as zero/nonzero 

*  /edge 

* * configures behavior of poll(2) on/value 

* * available only if pin can generate IRQs on input 

* * is read/write as " none" , "falling" , "rising" , or " both" 


*  /active low 


* * configures polarity of/value 

* * is read/write as zero/nonzero 

* * also affects existing and subsequent "falling" and " rising" 
* /edge configuration 

*/ 
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以 上 是 GPIO 框架 抽象 层 的 实现 ， 体 系 结构 具体 的 实现 主要 就 是 实现 并 注册 结构 体 gpio_ 
chip 及 相关 的 操作 。 从 整体 上 来 说 GPIO 框架 还 是 简单 直接 的 。 


4.8.3 TLJ- GPIO 管理 相关 实现 详解 


TI 芯片 GPIO 管理 的 具体 实现 仍 是 以 DM 3730 为 例 ， 关 于 GPIO 模块 本 身 ，DM 81XX 等 
处 理 器 与 DM 3730 是 相同 的 ， 只 是 一 些 寄存 器 地 址 和 参数 不 同 。 

先 来 看 看 硬件 的 框架 和 细节 。DM 3730 GPIO 子 系统 框图 如 图 4-50 ras, 318 (DM 
3730 心 片 手册 》 中 第 3478 页 框图 。 
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图 4-50 DM 3730 GPIO 子 系统 框 区 














JAB 4-50 可 见 ，DM 3730 一 共有 6 组 GPIO 管理 单元 ， 每 组 管理 32 个 GPIO, HP 
GPIO1 是 比较 特殊 的 ， 其 原因 在 硬件 电源 管理 技术 中 已 提 到 ，GCPIO1 TE WKUP domain 中 ， 
而 其 他 组 的 GPIO 在 其 他 的 power domain 中 。WKUP domain 是 特殊 的 power domain, ， 该 do- 
main 的 模块 会 一 直 供 电 。 在 每 组 GPIO 中 ， 除 了 标准 的 时 钟 之 外 ， 还 有 debounce clock 用 来 
进行 debounce 处 理 (主要 在 作为 input 时 去 拌 ， 避 人 免 拌 动产 生 的 错误 结果 ) ， 另 外 还 有 唤醒 
系统 的 功能 。GPIO 的 中 断 信号 同样 可 以 提供 给 ARM MPU 和 IVA DSP， 从 而 不 同 的 核 都 可 
以 对 外 部 的 GPIO 进行 操作 。 

XT GPIO 内 部 的 系统 设计 如 图 4-51 所 示 。 图 4-51 引 自 《DM 3730 芯片 手册 》 中 第 
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3490 页 框图 。 
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K| 4-51 DM 3730 GPIO 内 部 系统 设计 图 


从 图 4-51 中 可 见 ， 一 组 GPIO 的 设置 寄存 器 接口 ， 主 要 由 系统 控制 、 中 断 管理 、 去 拌 
模块 、 输 入 输出 特性 等 不 同 功能 设置 寄存 器 对 相应 的 功能 进行 设置 。 





针对 软件 的 实现 ， 使 用 GPIO lib 提供 
控制 管理 的 需求 ， 所 以 在 芯片 代码 中 对 g 
成 gpio_bank 结构 ， 详 细 内 容 如 下 : 


struct gpio_bank | 
unsigned long pbase; 
void ^ iomem * base; 
ul6 irq; 
ul6 virtual irq. start ; 


int method; 


的 管理 实体 gpio. chip 不 能 满足 DM 3730 关于 GPIO 


pio. chip 进行 了 封装 并 加 入 芯片 特定 的 管理 属性 形 


#if defined( CONFIG_ARCH_OMAP16XX) | defined( CONFIG_ARCH_OMAP2PLUS) 


u32 suspend_wakeup; 

u32 saved wakeup; 
#endif 

u32 non wakeup. gpios; 


u32 enabled non wakeup. gpios; 


u32 saved. datain ; 
u32 saved. fallingdetect ; 


u32 saved. risingdetect ; 
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E 


u32 level_mask; 

u32 toggle_mask; 
spinlock_t lock; 

struct gpio_chip chip; 
struct clk * dbck; 

u32 mod_usage; 

u32 dbck, enable. mask ; 
struct device * dev; 
bool dbck flag; 


int stride; 


作为 DM 3730 芯片 GPIO 管理 的 核心 数据 结构 ，gpio_bank 中 已 经 包含 了 GPIO lib 需要 
的 gpio_chip， 这 样 的 实现 符合 面向 对 象 的 方法 ， 从 体系 结构 层次 的 角度 考虑 也 是 底层 包含 
上 层 的 内 容 。 另 外 gpio_bank 中 还 包含 了 用 于 GPIO 控制 的 属性 ， 


中 用 到 。 





下 面 介绍 详细 的 实现 。 
1. 重要 的 初始 化 实现 
对 于 GPIO 功能 芯片 特殊 的 实现 和 GPIO lib 的 接口 就 是 gpio_chip。 
也 和 填充 gpio_chip 以 及 注册 gpio_chip 相关 ， 这 些 都 是 在 初始 化 中 实现 的 ， 了 解 这 些 初 始 化 
工作 就 可 以 大 致 了 解 GPIO 芯片 的 特性 。DM 3730 相关 的 初始 化 函数 是 omap_gpio_chip_init, 
详细 的 内 容 和 注释 如 下 : 


static void — init omap_gpio_chip_init(struct gpio bank * bank) 


| 
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int j; 


static int gpio; 


/初始 化 该 组 GPIO 的 使 用 情况 
bank -> mod. usage 20; 
Je 
* REVISIT eventually switch from OMAP - specific gpio structs 
* over to the generic ones 
*/ 
// 设 置 gpio_chip 相关 的 接口 主要 是 GPIO 相关 功能 
bank -> chip. request = omap_gpio_request; 
bank -> chip. free = omap. gpio. free; 
bank -> chip. direction, input = gpio, input ; 
bank -> chip. get = gpio. get ; 
bank -> chip. direction. output = gpio. output ; 


bank -> chip. set. debounce = gpio. debounce ; 


这 些 








属性 会 在 具体 的 操作 


芯片 特殊 实现 本 刁 


bank -> chip. set = gpio_set; 
bank -> chip. to_irq = gpio_2irq; 
if( bank_is_mpuio( bank) ) | 
/该 分 文 是 指 ARM MPU 中 有 GPIO 控制 器 的 情况 。DM 3730 不 是 该 情况 
bank -> chip. label = " mpuio" ; 
#ifdef CONFIG_ARCH_OMAPI6XX 


bank -> chip. dev = &omap. mpuio. device. dev; 





#endif 
bank -> chip. base = OMAP MPUIO(0) ; 
| else | 
/设置 该 组 GPIO 的 起 始 GPIO 号 。 对 多 组 GPIO 的 情况 需要 按照 顺序 对 该 函数 进行 
// 调 用 
bank -> chip. label =" gpio" ; 
bank -> chip. base = gpio; 
gpio += bank_width; 
| 
// 设 置 该 组 gpio_bank 管理 的 GPIO 数目 
bank -> chip. ngpio = bank_width; 














// 注 册 gpio_chip 并 和 所 管理 的 gpio_dese 进行 绑 定 
gpiochip_add( &bank -> chip) ; 


// 下 面 对 一 组 GPIO 所 有 的 GPIO 对 应 的 中 断 处 理 进行 初始 化 


for( j = bank -> virtual_irq_start; 





j < bank -> virtual irq. start bank, width; j ++ ) | 
// 获 得 某 个 GPIO 对 应 的 中 断 描述 符 


struct irq desc * d = irq to desc(j) ; 





lockdep. set. class( &d -> lock, &gpio. lock, class) ; 
// EP p ni HI RA BE I AH. gpio. bank 
set, irq. chip. data(j, bank) ; 
// Vit ER AE A SP o ll i Lb ZF], DM 3730 是 gpio_irq_chip 
if( bank, is. mpuio( bank ) ) 
set, irq. chip(j, &mpuio_irq_chip) ; 





else 
set irq chip(j, &gpio irq chip) ; 
// 设 置 简单 的 中 断 处 理 handler, 该 handler 需要 外 部 进行 中 断 控制 器 的 处 理 
set_irq_handler(j, handle_simple_irq) ; 
// 设 置 该 中 断 为 无 效 状 态 
set_irq_flags(j, IRQF_VALID) ; 











| 
// 这 里 是 针对 中 断 级 联 的 情况 ,之 前 是 针对 该 组 GPIO 的 每 个 GPIO 的 中 断 处 理 。 而 从 系统 的 
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代码 解析 。 
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| 





/角度 不 能 为 每 个 gpio 都 提供 对 ARM 的 中 断 信 号 ,而 是 每 组 GPIO 提供 一 个 对 ARM 的 中 断 
// 信 号 ,这 里 需要 对 于 该 组 GPIO 对 ARM 的 中 断 进 行 初始 化 。 这 里 要 设置 中 断 为 级 联 状态 
// 及 其 handler, 保 证 该 中 断 不 能 被 其 他 模块 申请 。 

set_irq_chained_handler( bank -> irq, gpio_irq_handler) ; 

// 设 置 中 断 处 理 的 私有 数据 为 当前 gpio_bank 

set_irq_data( bank -> irq, bank) ; 




















分 析 了 重要 的 初始 化 函数 omap_gpio_chip_init 之 后 ， 可 见 GPIO 分 为 两 个 重要 的 功能 组 ， 
一 组 是 gpio chip 相关 的 功能 接口 ， 男 一 组 是 和 中 断 相关 的 功能 。 下 面 分 两 部 分 进行 详细 的 











2. gpio_chip 功能 接口 
GPIO 的 功能 主要 是 通过 gpio_chip 的 功能 接口 实现 的 。 下 面 对 相 关 实 现代 码 进行 详细 


解析 : 


// 请 求 获 得 特定 GPIO 的 接口 


static int omap_gpio_request( struct gpio_chip * chip, unsigned offset) 


| 


// 首 先 获 得 该 组 GPIO 的 芯片 级 管理 实体 gpio. bank 


struct gpio_bank * bank = container_of(chip, struct gpio bank, chip) ; 





unsigned long flags; 





// 由 于 该 函数 相当 于 在 库 函 数 中 调用 ,所 以 使 用 高 级 别 的 锁 保 护 
spin, lock, irqsave( &bank -> lock, flags) ; 


/ * Set trigger to none. You need to enable the desired trigger with 
* request, irq( ) or set, irq type( ). 
*/ 
// 功 能 接口 就 取消 中 断 触发 ,在 系统 中 断 接口 中 进行 相应 的 设置 
_set_gpio_triggering( bank, offset, IRQ TYPE NONE) ; 


if( ! epu, class is omapl ( ) ) | 
if( !bank -> mod, usage) | 
// 该 组 GPIO 中 申请 的 第 一 个 CPIO , 则 使 能 该 模块 
void _ iomem * reg = bank -> base; 
u32 ctrl; 





// 先 获得 control 寄存 器 的 地 址 

if( cpu. is omap24xx( ) || cpu_is_omap34xx() ) 
reg += OMAP24XX_GPIO_CTRL; 

else if( cpu_is_omap44xx() || cpu_is_ti816x() ) 


reg += OMAP4_GPIO_CTRL; 
ctl 2 raw, readl(reg) ; 
/ * Module is enabled, clocks are not gated ** / 
// 使 能 模块 和 时 钟 
ctrl & =OxFFFFFFFE; 
. raw writel(ctrl, reg); 
} 
/标记 该 GPIO 申请 标识 
bank -> mod_usage |= 1 << offset; 
| 
/人 /释放 锁 
spin, unlock, irqrestore( &bank -> lock, flags) ; 


return 0; 


// 释 放 某 个 GPIO 的 接口 
static void omap. gpio free(struct gpio_chip * chip, unsigned offset) 
| 

// 首 先 获得 该 组 GPIO 的 芯片 级 管理 实体 gpio_bank 


struct gpio_bank * bank = container_of( chip, struct gpio bank, chip) ; 














unsigned long flags; 


// 锁 保护 
spin, lock, irqsave( &bank -> lock, flags) ; 


#if defined( CONFIG; ARCH. OMAP2) || defined( CONFIG. ARCH, OMAP3) 
if( bank -> method == METHOD. GPIO. 24XX) | 
// GPIO 要 释放 清除 GPIO 唤醒 功能 
/ * Disable wake — up during idle for dynamic tick * / 
void — iomem * reg = bank —> base + OMAP24XX_GPIO_CLEARWKUENA; 
. raw  writel( 1 << offset, reg) ; 
| 
#endif 
#if defined( CONFIG_ARCH_OMAP4 ) | defined ( CONFIG_ARCH_TI816X ) 
if( bank -> method == METHOD_GPIO_44XX) | 
/ * Disable wake — up during idle for dynamic tick * / 
void | iomem * reg = bank —> base + OMAP4_GPIO_IRQWAKENO; 
_ raw_writel(1 << offset, reg) ; 
| 
#endif 


265 


266 


// 设 置 GPIO 为 输入 的 接口 


static int gpio_input( struct gpio_chip * chip, unsigned offset) 


if( ! epu, class is omapl ( ) ) | 
/标记 GPIO 释放 
bank -> mod, usage & = ~ (1 < offset) ; 
if( !bank -> mod, usage) | 
// 该 组 GPIO 都 已 经 释放 , 则 需要 disable 模块 关闭 clock 
void | iomem * reg = bank -> base; 


u32 ctrl; 





// 获 得 control 寄存 器 

if( cpu_is_omap24xx() || cpu_is_omap34xx( ) ) 
reg += OMAP24XX_GPIO_CTRL; 

else if( cpu, is omap44xx( ) | cpu_is_ti816x() ) 
reg += OMAP4_GPIO_CTRL; 





ctrl=__ raw. readl(reg) ; 

/ * Module is disabled, clocks are gated * / 
// disable 该 模块 关闭 clock 

ctrl |= 1; 


= raw_writel(ctrl, reg); 


| 

// 由 于 GPIO 可 能 做 中 断 , 所 以 在 释放 时 需要 清除 中 断 相 关 状 态 等 操作 
_reset_gpio( bank, bank —> chip. base + offset) ; 

// 释 放 锁 

spin_unlock_irqrestore( &bank -> lock, flags) ; 





























struct gpio_bank * bank; 


unsigned long flags; 





// 首 先 获得 该 组 GPIO 的 芯片 级 管理 实体 gpio_bank 
bank = container of(chip, struct gpio_bank, chip) ; 














/A/ 锁 保护 

spin, lock, irqsave( &bank -> lock, flags) ; 
/设置 方向 为 输入 

_set_gpio_direction( bank, offset, 1) ; 
/释放 锁 


spin, unlock, irqrestore( &bank -> lock, flags) ; 


return 0; 





// 获 得 GPIO 信号 的 值 
static int gpio_get( struct gpio_chip * chip, unsigned offset) 
| 

struct gpio_bank * bank; 

void iomem * reg; 

int gpio; 

u32 mask; 


/获得 GPIO 表示 方向 状态 寄存 天 
gpio = chip —> base + offset; 

bank = get_gpio_bank( gpio) ; 

reg = bank -> base; 


mask = 1 << get. gpio. index( gpio) ; 


// 根 据 方向 状态 获得 GPIO 的 值 
if( gpio_is_input( bank, mask) ) 

return _get_gpio_datain( bank, gpio) ; 
else 

return _get_gpio_dataout(bank, gpio) ; 


| 
// 设 置 GPIO 为 输出 并 设置 输出 值 
static int gpio_output( struct gpio_chip * chip, unsigned offset, int value) 


| 












































struct gpio bank * bank; 


unsigned long flags; 





// 首 先 获得 该 组 GPIO 的 芯片 级 管理 实体 gpio. bank 
bank = container_of( chip struct gpio_bank, chip) ; 
/A/ 锁 保护 

spin_lock_irqsave( &bank -> lock, flags) ; 

// 设 置 输出 值 

_set_gpio_dataout( bank, offset, value) ; 

/设置 GPIO 方向 为 输出 

_set_gpio_direction( bank, offset, 0) ; 

// FETE 

spin, unlock, irqrestore( &bank -> lock, flags) ; 











return 0; 








// 设 置 去 抖 模块 


static int gpio_debounce( struct gpio chip * chip, unsigned offset, 
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unsigned debounce ) 


struct gpio_bank * bank; 


unsigned long flags; 


























/首先 获得 该 组 GPIO 的 芯片 级 管理 实体 gpio_bank 
bank = container_of( chip struct gpio_bank, chip) ; 





if( !bank -> dbck) | 
/如果 没 有 获得 去 抖 模块 相关 时 钟 , 则 首先 获得 并 打开 相关 时 钟 
bank -> dbck = clk_get( bank -> dev, " dbclk" ) ; 
if( IS ERR( bank -> dbck) ) 
dev. err( bank -> dev, "Could not get gpio dbek Wn" ) ; 








/获得 锁 

spin_lock_irqsave( &bank -> lock, flags) ; 

// 设 置 去 拌 功 能 及 参数 

_set_gpio_debounce( bank, offset, debounce) ; 
/释放 锁 

spin, unlock, irqrestore( &bank -> lock, flags) ; 


return 0; 














// 设 置 GPIO 的 值 


static void gpio_set( struct gpio_chip * chip, unsigned offset, int value) 


| 











struct gpio_bank * bank; 


unsigned long flags; 


// 首 先 获得 该 组 GPIO 的 芯片 级 管理 实体 gpio_bank 
bank = container_of( chip, struct gpio_bank, chip) ; 
/获得 锁 

spin, lock, irqsave( &bank -> lock, flags) ; 

// 设 置 GPIO 输出 值 

_set_gpio_dataout( bank, offset, value); 

// 释 放 锁 

spin, unlock, irqrestore( &bank -> lock, flags) ; 























// 获 得 GPIO 对 应 的 中 断 号 
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static int gpio_2irq( struct gpio chip * chip, unsigned offset) 
| 


struct gpio_bank * bank; 




















// 首 先 获 得 该 组 GPIO 的 芯片 级 管理 实体 gpio_bank 
// 该 组 GPIO 的 起 始 中 断 号 加 上 该 GPIO 的 偏 移 就 是 GPIO 对 应 的 中 断 号 
bank = container_of( chip, struct gpio_bank, chip) ; 

















return bank -> virtual irq start + offset; 


| 


对 GPIO 相关 功能 的 芯片 特殊 实现 ， 主 要 进行 函数 功能 的 分 析 ， 具 体 到 子 函 数 的 细节 
可 以 查看 相关 代码 。 

3. GPIO 中 断 相 关 实 现 

GPIO 中 断 相关 的 实现 ， 最 主要 的 是 中 断 控制 器 相关 的 接口 实现 以 及 中 断 级 联 中 GPIO 
组 的 中 断 处 理 函 数 。 

先 来 看 看 GPIO 的 中 断 控制 器 相关 接口 。 这 里 实际 实现 了 级 联 的 中 断 处 理 。 











static struct irq_chip gpio_irq_chip = | 


. name ="GPIO" , 

. shutdown ^ -gpio irq shutdown, 
.ack = gpio_ack_irq, 

. mask = gpio_mask_irq, 

. unmask = gpio unmask irq, 


.set type = gplo irq type, 
. set. wake = gpio. wake. enable, 


ls 
该 中 断 控 制 器 负责 一 组 GPIO 的 中 断 处 理 ， 详 细 的 接口 代码 分 析 如 下 : 


// 关 掉 中 断 
static void gpio_irq_shutdown( unsigned int irq) 


| 





// 首 先 根据 中 断 号 获得 GPIO 值 

unsigned int gpio = irq - IH_GPIO_BASE; 

// 找 到 对 应 的 GPIO 组 

struct gpio_bank * bank = get_irq_chip_data( irq) ; 

















A/ 清除 中 断 状态 关闭 相应 GPIO 中 断 
_reset_gpio(bank, gpio) ; 





// SPT tll ai TAP MR SER ELE T eT B FP UST 
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static void gpio ack, irq( unsigned int irq) 


| 














/首先 根据 中 断 号 获得 GPIO 值 

unsigned int gpio = irq - IH_GPIO_BASE; 

// 找 到 对 应 的 GPIO 组 

struct gpio_bank * bank = get_irq_chip_data( irq) ; 





// 清 楚 中 断 状态 位 


_clear_gpio_irqstatus( bank, gpio) ; 





// Be illc rp Br 
static void gpio mask. irq( unsigned int irq) 


| 











/首先 根据 中 断 号 获得 GPIO f 

unsigned int gpio = irq - IH_GPIO_BASE; 

// 找 到 对 应 的 GPIO 组 

struct gpio_bank * bank = get_irq_chip_data( irq) ; 

















// disable 相应 中 断 

_set_gpio_irqenable( bank, gpio, 0); 

// 关 闭 触 发 功能 

_set_gpio_triggering( bank, get_gpio_index( gpio), IRQ_TYPE_NONE); 


A/ 开放 中 断 功 能 
static void gpio unmask, irq( unsigned int irq) 


| 








A/ 首先 根据 中 断 号 获得 GPIO 值 

unsigned int gpio = irq - IH_GPIO_BASE; 

// 找 到 对 应 的 GPIO 组 

struct gpio_bank * bank = get_irq_chip_data( irq) ; 














unsigned int irq_mask =1 < < get_gpio_index( gpio) ; 
// 获 得 中 断 描述 符 并 检测 触发 方式 
struct irq_dese * desc =irq_to_desc(irq); 


u32 trigger = desc -> status & IRQ_TYPE_SENSE_MASK; 




















// 如 果 之 前 已 经 设置 触发 方式 则 设置 触发 
if( trigger) 











_set_gpio_triggering( bank, get_gpio_index( gpio), trigger) ; 


/* For level - triggered GPIOs, the clearing must be done after 
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* the HW source is cleared, thus after the handler has run * / 
// 电 平 触发 的 中 断 需要 先 清 除 具 体 的 GPIO 中 断 状态 
if( bank -> level. mask & irq_mask) | 









































_set_gpio_irqenable( bank, gpio, 0) ; 


—clear gpio irqstatus( bank, gpio) ; 








// 使 能 GPIO 中 断 
_set_gpio_irqenable( bank, gpio, 1) ; 


// 设 置 中 断 触 发 类 型 的 接口 
static int gpio_irq_type( unsigned irq, unsigned type) 


| 























struct gpio bank * bank; 
unsigned gpio; 
int retval; 


unsigned long flags ; 


// 获 得 GPIO 号 

if(! cpu_class_is_omap2() && irq >IH_MPUIO_BASE ) 
gpio = OMAP MPUIO( irq - IH_MPUIO_BASE) ; 

else 


gpio = irq - IH. GPIO BASE; 


if(check gpio(gpio) « 0) 
return — EINVAL; 


if(type & ~ IRQ TYPE SENSE MASK) 
return — EINVAL; 


/ * OMAPI allows only only edge triggering * / 
if( ! epu, class is omap2( ) 
&&(type &(IRQ. TYPE, LEVEL LOW | IRQ TYPE LEVEL HIGH) ) ) 
return — EINVAL; 


// 获 得 GPIO 所 在 的 组 管理 实体 

bank = get_irq_chip_data( irq) ; 

// 获 得 GPIO 组 管理 实体 锁 

spin, lock, irqsave( &bank -> lock, flags) ; 

设置 中 断 触 发 方式 

retval = _set_gpio_triggering( bank, get_gpio_index( gpio) , type) ; 
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if(retval 220) | 


struct irq desc * d = irq to. desc( irq) ; 


d -> status & = ~ IRQ TYPE SENSE MASK ; 
d —» status | = type; 

| 

/释放 GPIO 组 管理 实体 锁 

spin, unlock, irqrestore( &bank -> lock, flags) ; 


/根据 中 断 触 发 方式 设置 合适 的 中 断 处 理 handler, 33:5 handler 由 ARM 体系 结构 
// 代 码 统一 提供 ,属于 中 断 触 发 处 理 的 标准 handler, 中 断 处 理 章 节 介 绍 差异 
if(type &(IRQ TYPE LEVEL LOW | IRQ TYPE LEVEL HIGH)) 

. set irq handler unlocked(irq, handle level, irq) ; 
else if(type &(IRQ. TYPE EDGE FALLING | IRQ. TYPE EDGE, RISING) ) 





























. set, irq handler unlocked( irq, handle edge irq) ; 


return retval ; 


// GPIO 唤醒 功能 设 定 接口 


static int gpio_wake_enable( unsigned int irq, unsigned int enable) 


| 





/首先 根据 中 断 号 获得 GPIO 值 
unsigned int gpio = irq - IH_GPIO_BASE; 











struct gpio_bank * bank; 


int retval; 


if(check gpio(gpio) < 0) 
return — ENODEV ; 
// 获 得 GPIO 组 管理 实体 
bank = get_irq_chip_data( irq) ; 
// 根 据 enable 参数 设置 GPIO 唤醒 功能 
retval = _set_gpio_wakeup( bank, get_gpio_index( gpio), enable) ; 























return retval; 


| 





从 中 可 见 ，GPIO 不 仅 有 基本 的 中 断 操作 ， 还 有 唤醒 系统 的 能 力 ， 所 以 提供 了 中 断 控 制 
ar set wake 的 接口 〈 该 接口 是 老 的 接口 ， 但 是 可 以 通过 新 的 接口 irq_set_wake 转换 调用 ， 
内 核 中 断 处 理 框 架 irq_chip_set_defaults 会 建立 这 种 转换 ) 。 

接 下 来 解析 一 下 级 联 的 中 断 处 理 ， 由 于 ARM 无 法 获得 一 组 GPIO 中 具体 哪个 GPIO 上 报 的 中 
断 ， 所 以 需要 通过 该 级 联 中 断 处 理 ， 进 行 具 体 的 解析 并 需要 对 具体 的 GPIO 中 断 进 行 处 理 。 
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// 级 联 的 中 断 处 理 函数 
static void gpio_irq_handler( unsigned int irq, struct irq_desc * desc) 
| 

void | iomem * isr_reg = NULL; 

u32 isr; 

unsigned int gpio_irq, gpio index; 

struct gpio_bank * bank; 

u32 retrigger =0; 


int unmasked =0; 









































// 先 对 上 层 的 中 断 控 制 器 进行 ack 操作 ,主要 是 由 于 这 里 需要 进行 多 个 
// 中 断 的 处 理 


dese -> chip -> ack( irq) ; 





/获得 GPIO 组 管理 实体 
bank = get, irq-. data( irq) ; 


/获得 正确 的 中 断 状态 寄存 器 地 址 
#if defined( CONFIG_ARCH_OMAP2) || defined( CONFIG_ARCH_OMAP3) 
if( bank -> method == METHOD_GPIO_24XX) 
isr reg = bank -> base + OMAP24XX GPIO IRQSTATUSI ; 
#endif 
#if defined( CONFIG_ARCH_OMAP4) || defined( CONFIG ARCH. TI816X ) 
if( bank -> method == METHOD GPIO 44XX) 
isr reg = bank -> base + OMAPA GPIO IRQSTATUSO ; 
#endif 


if( WARN, ON( ! isr reg) ) 


goto exit; 

















// 这 里 是 循环 检查 直到 所 有 需要 处 理 的 中 断 处 理 完 
while(1) | 
u32 isr_saved, level_mask =0; 


u32 enabled; 











// 检 查 哪些 GPIO 的 中 断 enable 
enabled = _get_gpio_irqbank_mask (bank) ; 
// 查 看 哪些 GPIO 上 报 了 中 断 


isr saved =isr =__raw_readl(isr_reg) & enabled; 





if( cpu, is; omapl5xx( ) &&( bank -> method == METHOD MPUIO) ) 
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isr & = 0Ox0000ffff ; 








// 检 查 哪 些 是 电 平 触发 中 断 
if( cpu_class_is_omap2( ) ) | 











level, mask = bank -> level, mask & enabled; 


/ * clear edge sensitive interrupts before handler(s) are 

called so that we don' t miss any interrupt occurred while 

executing them * / 

// 对 于 边沿 触发 的 中 断 现 在 可 以 先 清除 ,这 样 可 以 避免 错过 中 断 
_enable_gpio_irqbank( bank, isr saved & ~ level mask, 0) ; 
clear gpio irqbank( bank, isr saved & ~ level mask); 


_enable_gpio_irqbank( bank, isr saved & - level mask, 1) ; 


/ * if there is only edge sensitive GPIO pin interrupts 

configured, we could unmask GPIO bank interrupt immediately * / 

// 所 有 的 GPIO 都 是 边沿 触发 模式 ,并 且 上 一 级 中 断 控制 部 还 没有 umask 
A// 相 应 的 中 断 ,这 里 可 以 umask 相应 中 断 ,并 标记 已 经 umask 

if(! level mask && ! unmasked) | 




















unmasked - 1 ; 


desc -> chip -> unmask (irq) ; 


// 这 里 的 retrigger 原意 是 标记 在 处 理 过 程 中 发 生 的 中 断 , 但 是 实际 并 没有 
// 使 用 该 值 


1sr | = retrigger; 





retrigger =0; 





// 没 有 中 断 上 报 的 情况 就 退出 循环 
if( | isr) 
break; 


// 这 里 需要 获得 实际 的 GPIO 中 断 并 处 理 
// 首 先 获 得 该 组 GPIO 的 初始 中 断 号 
gpio_irg = bank —> virtual_irq_start; 

// 3 D Br fih e B5] ve 


for( ; isr | 20; isr >>=1, gpio_irq++) | 





gpio index = get. gpio index( irq to gpio( gpio_irq) ) ; 


// 没 有 触发 中 断 的 GPIO 跳 过 
if(! (isr &1)) 


continue ; 
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// 处 理 触 发 的 GPIO 中 断 ,此 处 为 实际 的 GPIO 中 断 ,相当 于 二 级 中 断 
generic handle irq( gpio_irq) ; 


| 





} 

/ * if bank has any level sensitive GPIO pin interrupt 

configured, we must unmask the bank interrupt only after 

handler(s) are executed in order to avoid spurious bank 

interrupt * / 

// 这 里 如 果 没 有 umask ,说 明 有 电 平 触发 的 中 断 ,需要 在 此 时 进行 umask 操作 
exit; 

if(! unmasked) 


desc -> chip -> unmask (irq) ; 



































| 


至 此 ， 关 于 GPIO 的 中 断 部 分 主要 框架 就 分 析 完 了 。 中 断 处 理 还 要 注意 电 平 触发 和 边沿 
触发 的 流程 是 不 同 的 ， 这 些 都 要 体现 在 级 联 的 中 断 处 理 中 。 


4.9 引 脚 复 用 (pin mux) 


引 脚 复 用 一 直 是 内 核 代 码 所 忽视 的 内 容 ， 而 对 SoC 来 说 又 十 分 重要 。SoC 中 包含 了 很 多 
功能 模块 ， 而 由 于 芯片 面积 的 限制 ， 其 引 脚 数目 也 是 受 限 的 ， 不 可 能 所 有 功能 模块 都 有 单独 
的 引 脚 ， 这 就 要 求 有 引 脚 复 用 。 


4.9.1 引 脚 复 用 的 基本 需求 


引 脚 通常 是 和 使 用 者 相关 的 ， 相 应 的 使 用 者 是 条 些 功 能 模块 。 要 使 得 功能 模块 能 够 找到 
其 对 应 的 引 脚 并 进行 正确 的 设置 ， 就 需要 引 脚 复 用 模块 对 每 个 引 脚 及 其 能 被 哪些 模块 使 用 进 
行 管理 。 这 其 中 的 方法 可 以 根据 需要 自行 设计 , 但 是 该 功能 是 引 脚 复 用 必须 实现 的 。 

另外 即使 是 同一 款 芯片 针对 不 同 的 应 用 场合 会 有 不 同 的 封装 方式 ， 而 对 引 脚 来 说 不 同 的 
封装 就 会 意味 着 引 脚 数目 的 差别 ， 这 样 对 引 脚 复 用 来 说 ， 不 同 的 封装 实际 的 管理 数据 又 会 有 
差别 ， 所 以 引 脚 复 用 还 要 和 封装 方式 结合 。 这 些 都 要 体现 在 实际 的 系统 中 。 

最 后 引 脚 复 用 还 需要 执行 时 能 够 对 引 脚 属性 以 及 功能 进行 配置 ， 以 实现 灵活 的 功能 ， 另 
外 电源 管理 也 是 需要 该 功能 的 。 


4.9.2 引 脚 复 用 框架 介绍 


关于 引 脚 复 用 框架 ， 一 直 以 来 Linux 内 核 并 没有 提供 统一 的 功能 框架 ， 此 功能 也 只 能 由 
芯片 厂商 来 完成 了 ， 直 到 最 近 几 版 内 核 才 采 用 STE 提出 的 pin control 架构 ， 从 而 显现 出 融合 
的 趋势 。 其 相应 的 框架 如 图 4-52 所 示 。 
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Device drivers can get pinctrl and 
state handles here 














Pinctrl core 









i] «[devm ]get() 
*[devm ]put() 
*lookup state() 
*select state() 









1 
pinctrl dev 


+name: const char * 


*enable() 
*disable() 





*get groups count(): int 

*get group name(selector:unsigned):const char * 
*get gorup pins(): int 

*pin dbg show() r 
+dt_node_to_map() GPIO reservation 
+gpio: unsigned 


+pinmux_request_gpio() 
pinctrl_pin_desc +pinmux_free_gpio() 
+pinmux_direction_input() 


+number: unsigned +name: const char * *pinmux direction output() 


* name: const char * *id: unsigned 
== = *base: unsigned 


*pin base: unsigned The GPIO subsystem can get a 
*npins: unsigned handle for reserving a GPIO pin 
*gc: struct gpio chip * 

















* name: const char * 
pt 








Pinconf 


<<interface>> 
pin_configuration 
人 +pin_config_get(config:unsigned long) can get to re- 
+pin_config_set(config:unsigned long) onfigure 


+pin_config_group_get(config:unsigned long) pins here 
+pin_config_group_set(config:unsigned long) 


图 4-52 pin control 系统 框架 





从 图 4-52 中 可 见 ，pin control 架构 对 使 用 引 脚 的 设备 、 引 脚 的 分 组 、 引 脚 的 描述 、 管 
脚 的 设置 都 进行 了 抽象 ， 再 将 它们 进行 合理 的 组 合 ， 并 与 具体 的 设备 模块 结合 进行 管理 ， 形 
成 统一 的 引 脚 复 用 管理 框架 。 

由 于 DM 3730 等 TL 芯片 在 实现 中 还 没有 出 现 pin control 架构 ， 而 是 使 用 TE 自己 设计 的 
引 脚 复 用 架构 。 后 续 是 以 芯片 为 主 进行 介绍 ， 所 以 对 于 pin control 的 设计 与 实现 就 不 进行 深 
和 地 介绍 了 ， 其 基本 的 思路 还 是 和 TI 的 引 脚 复 用 架构 类 似 ， 读 者 可 以 深入 了 解 TT 引 肢 复 用 
实现 ， 然 后 继续 深入 了 解 pin control 的 架构 。 


4.9.3 TI 芯片 引 脚 复 用 相关 实现 详解 


1. 硬件 引 脚 控制 寄存 器 
首先 来 看 看 硬件 上 引 肢 复 用 提供 给 软件 的 接口 寄存 器 ， 如 图 4-53 所 示 。 图 4-53 引 自 
(DM3730 芯片 手册 》 中 第 2449 的 表 。 
图 4-53 中 引用 的 只 是 DM3730 引 脚 控制 相关 寄存 器 的 一 部 分 ， 从 中 可 见 对 于 某 个 固定 
的 引 脚 可 能 会 有 不 同 的 模式 ， 而 不 同 的 模式 表示 该 引 脚 为 不 同 的 功能 模块 提供 服务 ， 特 殊 的 
是 safe_mode 并 不 为 具体 的 功能 模块 服务 。 从 硬件 的 角度 ， 引 脚 为 safe_mode 时 ， 即 使 打开 
276 
































































































































Register Name Physical Moded Mode1 Mode2 Mode3 Mode4 Mode5 Mode6 Mode7 
Address 

CONTROL_PADCONF_SDRC_CLK[31:16] 0x4800 2070 sdre_dgs0) 

CONTROL PADCONF SDRC DQS1[15:0] 0x4800 2074 sdrc_dqs1 

CONTROL_PADCONF_SDRC_DQS1[31:16] 0x4800 2074 | sdrc dqs2 

CONTROL PADCONF SDRC DQS3[15:0] 0x4800 2078 sdrc dqsà 

CONTROL, PADCONF. SDRC DQS3[31:16] 0x4800 2078  gpmc al gpio 34 safe mode 

CONTROL, PADCONF. GPMC, A2[15:0] 0x4800 207C  gpmc a2 gpio 35 safe mode 

CONTROL PADCONF GPMC A2[31:16] 0x4800 207C gpmc a3 gpio 36 safe mode 

CONTROL PADCONF GPMC A4[15:0] 0x4800 2080 | gpmc a4 gpio 37 | safe_mode 

CONTROL_PADCONF_GPMC_A4[31:16] 0x4800 2080 |gpmc_a5 gpio_38 safe_mode 

CONTROL_PADCONF_GPMC_A6[15:0] 0x4800 2084 | gpmc_aé gpio_39 safe_mode 

CONTROL_PADCONF_GPMC_A6[31:16] 0x4800 2084 gpmc a7 gpio 40 safe mode 

CONTROL PADCONF GPMC AB[15:0] 0x4800 2088 gpmc aB No 41 safe mode 

CONTROL PADCONF GPMC AB8[31:16] 0x4800 2088 | gpmc_a9 oe io 42 | safe_mode 
ei 

CONTROL PADCONF GPMC AT10[15:0] 0x4800 208C gpmc_a10 | sys_ndmar gpio 43 safe mode 
et 

CONTROL_PADCONF_GPMC_A10[31:16] 0x4800 208C | gpmc_d0 

CONTROL, PADCONF. GPMC, D1[15:0] 0x4800 2090 ^ gpmc di 

CONTROL PADCONF GPMC D1[31:16] 0x4800 2090 gpmc d2 

CONTROL PADCONF GPMC D3[15:0] üx4800 2084 | gpmc_d3 

CONTROL_PADCONF_GPMC_D3[31:16] 0x4800 2094 = gpmc_d4 

CONTROL PADCONF GPMC. D5[15:0] 0x4800 2098  gpmc d5 

CONTROL PADCONF GPMC D5[31:16] 0x4800 2098 gpmc d& 

CONTROL PADCONF GPMC D7[15:0] 0x4800 209C gpmc d? 

CONTROL, PADCONF. GPMC, D7[31:16] 0x4800 209C — gpmc d& gpio 44 | safe mode 

CONTROL PADCONF GPMC D9[15:0] 0x4800 20A0 gpmc d9 gpio 45 safe mode 

CONTROL PADCONF GPMC. D9[31:16] 0x480020A0 | gpmc_d10 io_46 safe_mode 

CONTROL_PADCONF_GPMC_D11[15:0] 0x4800 20A4  gpmc dil gpio_47 safe_mode 

CONTROL PADCONF GPMC D11[31:16] 0x4800 20A4 gpmc di2 gpio 48 safe mode 

CONTROL PADCONF GPMC D13[15:0] 0x4800 20AB | gpmc di3 io 49 | safe_mode 

CONTROL_PADCONF_GPMC_D13[31:16] 0x4800 20A8 |gpmc_d14 gpio_50 safe_mode 

CONTROL_PADCONF_GPMC_D15[15:0) 0x480020AC | gpmc_d15 gpio 51 safe mode 

CONTROL, PADCONF. GPMC, D15[31:16] 0x4800 20AC ^ gpmc ncsü 

CONTROL, PADCONF. GPMC. NCS1[15:0] 0x4800 20B0 gpmc ncs gpio 52 safe mode 
































图 4-53 DM3730 引 脚 复 用 相关 寄存 器 
输入 功能 硬件 也 不 会 出 现 误 传 信 号 的 问题 。 
引 脚 配置 寄存 器 的 设置 如 图 4-54 所 示 。 图 4-54 引 自 《DM 3730 芯片 手册 》 中 第 2444 
页 框图 。 





Pad configuration register name = pad configuration register field @Oxn name 
Pad configuration @0xn+1 Pad configuration @0xn 


Wake up Off mode value Pull MUXMODE Wake up Off made value Pull MUXMODE 
Pee 2225 3251 [Bel he aalaa 4573145: Isle 
31 30°29 28 27 26 25 24 23 22212019 18 17 16 15 14 13 12 1110 9 8 7 6543210 










INPUTENABLE PULLUDENABLE INPUTENABLE PULLUDENABLE 
OFFENABLE PULLTYPESELECT OFFENABLE PULLTYPESELECT 
OFFOUTENABLE OFFOUTENABLE 
OFFOUTVALUE OFFOUTVALUE 
OFFPULLUDENABLE OFFPULLUDENABLE 
OFFPULLTYPESELECT OFFPULLTYPESELECT 
WAKEUPENABLE WAKEUPENABLE 
WAKEUPEVENT WAKEUPEVENT 


sam-Düs 

















图 4-54 DM 3730 引 脚 配置 寄存 器 设置 
从 图 4-54 中 可 见 ， 引 脚 的 设置 除了 具体 针对 模块 功能 之 外 ， 还 有 不 同 的 引 脚 属性 配置 ( 比 
如 上 下 拉 ， 以 及 电源 管理 的 属性 )。 从 这 些 设置 的 内 容 可 见 ， 引 脚 复 用 属于 横 切 功能 ， 所 以 从 设 
计 的 角度 还 是 要 考虑 对 于 不 同 设备 的 支持 。 这 就 要 求 数据 结构 设计 合理 ， 并 且 要 有 通用 性 。 
2. 引 脚 复 用 管理 数据 结构 
下 面 看 看 TI 的 引 脚 复 用 的 重要 数据 结构 和 详细 说 明 。 
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/* x 
* struct omap_device_pad — device specific pad configuration 
* @ name: signal name 
* @ flags:pad specific runtime flags 
* @ enable: runtime value for a pad 
* @ idle: idle value for a pad 
* @ off: off value for a pad, defaults to safe mode 
* @ partition; mux partition 
* @ mux; mux register 
*/ 

// 某 个 设备 模块 的 某 个 引 脚 的 属性 


struct omap_device_pad | 


2 





char * name; 
/状态 标识 

u8 flags ; 
// 模 块 enable 时 的 值 

ul6 enable; 
// 模 块 idle 时 的 值 

ul6 idle; 
/模块 off 时 的 值 

ul6 off; 





A/ 所 属 的 引 脚 管理 组 
struct omap_mux_partition * partition; 
// 具 体 的 引 脚 控制 实体 


struct omap_mux * mux; 





























E 


/ k 
* struct omap_board_data — board specific device data 
* @ id; instance id 
* @ flags; additional flags for platform init code 
* @ pads; array of device specific pads 
* @ pads cnt; ARRAY SIZE( ) of pads 
*/ 
// 板 级 某 个 设备 使 用 引 脚 的 初始 化 数据 
struct omap_board_data | 
SBS , FEY ID 号 
int id; 
u32 flags ; 
/该 设备 所 有 引 脚 的 数据 
struct omap_device_pad * pads; 


/A 引 脚 数目 
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in tpads_cnt; 


/六 六 
* @ name; name of the current partition 
* @ flags: flags specific to this partition 
* @ phys: physical address 
* @ size; partition size 
* @ base; virtual address after ioremap 
* (9 muxmodes; list of nodes that belong to a partition 
* @ node; list node for the partitions linked list 
*/ 
// 这 里 是 控制 一 组 引 脚 的 结构 , 引 脚 控制 寄存 器 在 连续 的 物理 空间 为 一 组 


struct omap_mux_partition | 

















const char * name; 

u32 flags; 

// 寄 存 器 物理 地 址 

u32 phys; 

u32 size; 

// 映 射 地 址 

void __iomem * base; 

// 链 表 连 接 所 有 的 引 脚 控制 结构 omap. mux, entry ,其 中 包含 omap_mux 
struct list_headmuxmodes; 

// 链 表 连 接 多 个 管理 引 脚 的 控制 组 


struct list_headnode; 








E 
/** 
* struct omap_mux — data for omap mux register offset and it’s value 
* @ reg. offset; mux register offset from the mux base 
* @ gpio: GPIO number 
* (9 muxnames ; available signal modes for a ball 
* @ balls: available balls on the package 
* @ partition; mux partition 
*/ 
// 具 体 的 控制 某 个 引 脚 的 设置 
struct omap_mux | 
// 在 一 组 padconf 寄存 器 中 的 偏 移 值 
ul6 reg offset; 
// 该 寄存 器 对 应 的 GPIO fH 
ul6  gpio; 
#ifdef CONFIG_OMAP_MUX 
char * muxnames| OMAP_MUX_NR_MODES] ; 
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#ifdef CONFIG_DEBUG_FS 
char * balls| OMAP_MUX_NR_SIDES ] ; 
#endif 
#endif 
E 


/** 
* struct omap_board_mux — data for initializing mux registers 
* @ reg offset; mux register offset from the mux base 
* @ mux_value: desired mux value to set 
*/ 
// 初 始 化 时 使 用 的 结构 用 于 特定 引 脚 的 属性 设置 


struct omap_board_mux | 


























ul6 reg_offset; 
ul6 value; 


区 


// 下 面 是 omap_device_pad 中 flag 的 不 同 标识 位 的 含义 
#define OMAP_DEVICE_PAD_ENABLED BIT(7) /x Not needed for board 一 *.c */ 
#define OMAP. DEVICE PAD REMUX BIT(1) /%* Dynamically remux a pad, 

needs enable, idle and off 

values */ 


#define OMAP. DEVICE PAD WAKEUP BIT(0) /* Pad is wake — up capable */ 


3. 引 脚 复 用 管理 相关 函数 
引 脚 的 管理 分 为 整体 和 设备 模块 相关 两 部 分 。 先 来 看 看 整体 的 引 脚 管理 ， 主 要 形成 
omap_mux_partition 的 信息 ， 具体 的 代码 与 分 析 如 下 : 





// YE ERE. machine, desc 中 的 init_machine 调用 
// 主 要 是 对 每 个 连续 的 partition 的 设置 时 会 调用 . 进而 产生 相应 
// 的 partition 管理 信息 


int __init omap_mux_init(const char * name, u32 flags, 








u32 mux_pbase, u32 mux_size, 
struct omap_mux * superset, 

struct omap_mux * package. subset , 
struct omap. board. mux * board, mux, 


struct omap. ball * package. balls) 
struct omap mux, partition * partition; 


// 4] li partition 管理 结构 
partition = kzalloc ( sizeof( struct omap. mux, partition) , GFP. KERNEL) ; 





if( ! partition) 
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return — ENOMEM; 


// 对 于 partition 管理 结构 赋值 

partition — > name = name; 

// iK flag 主要 为 

//#define OMAP MUX REG SBIT(1 < < 0) 
//#define OMAP MUX GPIO IN MODE3(1 < < 1) 
partition — > flags = flags; 

//size 为 有 多 少 pin mux 配置 属性 ,主要 是 寄存 器 数量 
partition — > size = mux, size; 

// 寄 存 器 物理 基地 址 

partition — > phys = mux_pbase; 

// 获 得 虚拟 地 址 ,主要 为 后 续 的 read/write 操作 提供 虚拟 地 址 


partition — > base = ioremap( mux_pbase, mux_size) ; 






































if(! partition ->base) | 
pr err(" 96s; Could not ioremap mux partition at 0x%08x\n" , 
— func  , partition —» phys) ; 
return — ENODEV ; 





// 初 始 化 该 partition 的 pin mux 链表 
INIT_LIST_HEAD( &partition -> muxmodes) ; 


// 每 次 调用 该 函数 管理 partition 的 链表 都 会 增加 
list_add_tail( &partition -> node, &mux_partitions) ; 








mux_partitions_cnt ++ ; 
pr info(" 96s; Add partition; #%d: 96s, flags; %x\n", _ fune |, 


mux, partitions cnt, partition -> name, partition —> flags) ; 





// 对 封装 进行 检查 必要 时 生成 debugfs 的 信息 
omap_mux_init_package( superset, package_subset, package_balls) ; 
// 实 例 化 partition 的 pin mux 链表 ,包括 DM 3730 所 有 引 脚 的 属性 
omap_mux_init_list( partition, superset) ; 

// 板 级 信号 的 特别 配置 


omap_mux_init_signals( partition, board_mux) ; 








可 





return 0; 





这 些 工作 主要 是 在 板 级 初始 化 的 时 候 做 。 板 级 初始 化 阶段 就 可 以 进行 特定 的 引 脚 设置 工 
作 ， 相 应 的 引 脚 参数 是 由 特定 的 omap_board_mux 来 进行 设置 ， 在 board - omap3evm. c 中 进 
行 相关 设置 的 代码 如 下 : 
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static struct omap_board_mux omap35x, board mux[ ] __initdata = | 
OMAP3, MUX(SYS NIRQ, OMAP MUX, MODEO | OMAP_PIN_INPUT_PULLUP | 
OMAP_PIN_OFF_INPUT_PULLUP | OMAP PIN OFF OUTPUT LOW | 
OMAP_PIN_OFF_WAKEUPENABLE), 





| . reg. offset = OMAP_MUX_TERMINATOR |, 
F 


与 设备 相关 的 引 脚 管理 的 接口 函数 和 详细 分 析 如 下 : 





// 此 变量 为 存放 bootargs 中 的 mux 的 配置 说 明 
// 通 过 omap_mux = 来 设置 . 


static char * omap_mux_options; 




















//omap3 所 有 的 GPIO 都 是 通过 mode4 来 配置 的 ,并 且 GPIO 号 在 不 同 的 pin 
// 没 有 重复 

// 该 函数 主要 是 对 相应 的 GPIO pin 进行 设置 ,设置 成 GPIO 使 用 ,将 pin mux 
// 配 置 成 val 的 值 ,val 为 pin 的 inputenable .chip off 和 wakeup 时 的 属性 
// 该 功能 通常 在 board 的 相应 模块 初始 化 时 对 所 使 用 的 GPIO pin 进行 配置 


static int __init _omap_mux_init_gpio( struct omap_mux_partition * partition, 




















E 

















int gpio, int val) 


struct omap, mux entry *e; 

struct omap. mux * gpio mux = NULL; 
ul6 old. mode; 

ul6 mux, mode; 


int found 20; 








// 首 先 获 得 该 组 pin mux 的 链表 ,其 中 是 omap_mux 


struct list_head * muxmodes = &partition -> muxmodes; 








if(! gpio) 
return — EINVAL; 























/查找 相应 的 GPIO pin 的 配置 ,并 记录 查找 到 的 个 数 
list_for_each_entry(e, muxmodes, node) | 
struct omap_mux * m = &e -> mux; 
if( gpio == m -> gpio) | 
gpio_mux = m; 


found ++ ; 
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// 如 果 没 有 找到 或 者 找到 的 个 数 多 于 1 个 都 是 错 的 . 
if(found ==0) | 
pr_err("%s: Could not set gpio%i\n", __func__, gpio) ; 
return — ENODEV ; 





if( found >1) | 
pr_info("%s: Multiple gpio paths( 96 d) for gpio%i\n", _ func. , 
found, gpio) ; 


return — EINVAL; 


// 读 取 相应 的 pin 的 配置 
old. mode = omap_mux_read( partition, gpio_mux —> reg. offset) ; 
// 重 新 设置 pin 的 mode 为 GPIO, omap3 上 GPIO 的 mode 为 4. 
// 其 他 属性 不 修改 . 
mux, mode = val & ~ (OMAP MUX NR, MODES - 1) ; 
if( partition —> flags & OMAP MUX, GPIO IN MODE3) 

mux mode | = OMAP MUX MODE3; 











else 
mux mode | =OMAP_MUX_MODF4; 

pr. debug( " 96s; Setting signal 96s. gpio%i 0x%04x —»0x9604xWTn" , _ func. , 
gpio mux -> muxnames|0] , gpio, old mode, mux mode) ; 


omap. mux, write( partition, mux mode, gpio mux -> reg. offset) ; 


return 0; 


// 对 其 他 模块 的 设置 pin 为 GPIO 的 接口 

/由 于 每 个 GPIO 只 会 有 一 个 引 脚 与 之 相对 应 ,GPIO 又 需要 根据 GPIO 号 进行 
// 灵 活 简 单 的 设置 ,所 以 为 GPIO 单独 提供 设置 的 接口 
int init omap_mux_init_gpio( int gpio, int val) 


| 
































struct omap, mux, partition * partition; 


int ret ; 


// 遍 历 所 有 的 partition 查找 相应 的 GPIO pin 
// 并 将 相应 的 pin 配置 成 gpio 模式 . 
list_for_each_entry( partition, &mux_partitions, node) | 


ret = _omap_mux_init_gpio( partition, gpio, val); 
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if( ! ret) 


return ret; 


return — ENODEV ; 





// BAROK mode0. muxmode format 的 格式 查找 相应 的 pin mux 属性 
// 通 常 传人 的 参数 只 有 mode ,mode0 是 指 相 应 的 pin 在 mode0 时 的 名 字 . 


static int __init _omap_mux_get_by_name( struct omap_mux_partition * partition, 








const char * muxname, 


struct omap_mux * * found_mux) 


struct omap_mux * mux = NULL; 
struct omap_mux_entry * e; 
const char * mode_name; 


int found 20, found, mode, modeO. len 20; 








// 先 获得 partition 中 的 pin mux 列表 . 


struct list head * muxmodes = &partition —> muxmodes ; 


// 获 得 mode0. muxmode 中 的 muxmode 的 名 字 . 
// 如 果 没 有 muxmode 则 直接 取 mode0 


mode, name = strchr( muxname,' .' ); 





if( mode name) | 
modeO. len = strlen( muxname) - strlen ( mode, name) ; 
mode, name ++ ; 

| else | 


mode. name = muxname; 








H 
HE 


// FJ] mux pin 的 链表 ,查找 相应 的 pin mux Jz 
list. for each, entry( e, muxmodes, node) | 
char * mO. entry; 


int 1; 


mux = We -> mux; 


m0_entry = mux - » muxnames| 0] ; 





// 首 先 检 查 mode0 是 否 匹 配 


/ * First check for full name in mode0. muxmode format * / 











if( modeO0. len && strnemp( muxname, m0, entry, modeO, len) ) 
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continue ; 


/ * Then check for muxmode only * / 
// 这 里 检查 muxmode 是 否 匹配 ,之 前 如 果 
//1& fj muxmode , Jill] muxmode 为 mode0 ,这 里 相当 于 习 
// 新 比较 一 下 mode , 则 一 定 匹 配 

for(i=0; i « OMAP_MUX_NR_MODES; i++) | 


char * mode, cur = mux —>muxnames| i ] ; 





pa 





if( ! mode, cur) 


continue ; 


if( | stremp( mode, name, mode cur)) | 
* found. mux = mux; 
found ++ ; 


found, mode =i; 


if( found 221) | 
// 返 回 找到 的 pin mux 的 mode 属性 ,通常 为 0 


return found_mode; 








// 如 果 找 到 多 于 1 个 则 报错 . 
if(found >1) | 





pr_err("%s: Multiple signal paths( %i) for %s\n", __func_, 
found, muxname) ; 
return — EINVAL; 
} 


pr err(" 96s; Could not find signal % s\n", __func__, muxname) ; 


return — ENODEV ; 





// 该 图 数 通过 mode0. muxmode format 的 格式 查找 相应 的 pin mux 属性 
// 通 常 传人 的 参数 只 有 mode0 ,mode0 是 指 相应 的 pin 在 mode0 时 的 名 字 . 


static int __ init 


oul 





E 


omap. mux, get. by. name( const char * muxname, 


struct omap. mux, partition ** found. partition , 
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struct omap_mux * * found_mux) 


struct omap_mux_partition * partition; 








// 遍 历 所 有 partition ,查找 muxname 的 pin mux ,通过 传 址 参数 
// 返 回 相 应 的 partition 和 omap_mux ,函数 返回 相应 的 名 字 
// 和 该 pin 的 第 儿 个 mode 


list_for_each_entry( partition, &mux_partitions, node) | 














struct omap_mux * mux = NULL; 





int mux mode 2. omap mux get by name( partition, muxname, &mux) ; 
if(mux mode « 0) 


continue ; 


// 找 到 相应 的 pin mux 参数 返回 partition 和 omap_mux 
* found_partition = partition; 


* found_mux = mux; 


// 返 回 符合 相应 muxmode 的 mode 值 omap3 为 0~7 


return mux_mode; 


return — ENODEV ; 


// 该 函数 是 其 他 模块 的 接口 ,做 相应 pin mux 的 配置 . 
//val 为 input enable, pull up/pull down. 
//name 为 mode0. muxmode 模式 


int __init omap_mux_init_signal( const char * muxname, int val) 


| 





struct omap. mux partition * partition = NULL; 
struct omap. mux * mux = NULL; 
ul6 old. mode; 


int mux, mode; 





// 首 先 通过 muxname 找到 相应 的 配置 信息 ,以 及 参数 使 用 的 mode 


mux, mode = omap. mux, get, by name( muxname, &partition, &mux) ; 














if( mux, mode « 0) 


return mux, mode ; 


old. mode = omap_mux_read( partition, mux —> reg. offset) ; 
// 将 要 设置 的 mode 值 和 要 设置 的 val 值 组 合 . 


mux_mode | =val; 
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pr. debug( " 96s; Setting signal %s 0x%04x -—>0x%04x\n", 
_ func _, muxname, old mode, mux_mode) ; 
// 写 pin mux 寄存 器 。 


omap_mux_write( partition, mux mode, mux —> reg offset) ; 


return 0; 


// 针 对 omap. hwmod ,对 pin mux 进行 初始 化 配置 ,将 hwmod 的 所 有 pin 进行 
// 初 始 化 配置 ,并 返回 相应 的 omap_hwmod_mux_info, , 供 omap_hwmod 使 用 。 











AR 


日 于 该 函数 使 用 GFP_KERNEL 分 配 memory ,所 以 不 能 在 中 断 中 调用 . 





// Linux 内 核 还 没有 在 所 有 设备 模块 使 用 该 接口 ,不 过 该 接口 对 


//omap_hwmod 使 用 的 引 脚 设 置 还 是 很 有 意义 的 


Stru 











ct omap_hwmod_mux_info * __init 





omap_hwmod_mux_init( struct omap_device_pad * bpads, int nr_pads) 


| 


struct omap_hwmod_mux_info * hmux; 


int 1; 








// 如 果 传 入 参数 没有 包含 pad 属性 则 直接 返回 
if(! bpads || nr pads < 1) 
return NULL; 











// 分 配 相应 的 omap_hwmod_mux_info 空间 
hmux = kzalloc( sizeof( struct omap_hwmod_mux_info) , GFP_KERNEL) ; 
if( ! hmux) 
goto errl ; 
// 记 录 该 module 使 用 的 pad 数目 


hmux -> nr. pads = nr. pads; 














// 为 相应 的 pad 分 配 memory, pad 信息 包含 pin mux 寄存 带 信 息 

// 以 及 offmode 时 pin 的 属性 信息 

hmux -> pads = kzalloc( sizeof( struct omap_device_pad) * 
nr_pads, GFP_KERNEL) ; 

if(! hmux -> pads) 





goto eri2 ; 


// JJ omap. hwmod, mux. info 的 每 个 pad 信息 赋值 
for(i20; i < hmux -»nr pads; i++) | 





struct omap mux, parütion * partition; 


struct omap. device pad * bpad = &bpads[i], * pad = &hmux -> pads|[ i] ; 


struct omap_mux * mux; 
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int mux_mode; 














// 获 得 pin mux 属性 ,并 赋值 相应 的 partition 和 omap_mux 属性 


mux, mode = omap_mux_get_by_name(bpad -> name, &partition, &mux) ; 








if(mux_mode < 0) 

goto err3; 
if( ! pad -> partition) 

pad —> partition = partition; 
if( ! pad -> mux) 


pad —> mux = mux; 


// pad 名 赋值 
pad -> name = kzalloc( strlen( bpad -> name) + 1, GFP. KERNEL) ; 
if( ! pad -> name) | 


int j; 


for(j=i-1; j>=0; j--) 
kfree( hmux -> pads| j]. name) ; 


goto err3; 


| 


strepy( pad —» name, bpad -> name) ; 


//flags 和 offmode 的 属性 赋值 
pad —> flags = bpad —> flags; 





pad —> enable = bpad -> enable; 
pad —> idle = bpad -> idle; 
pad —> off = bpad -> off; 


pr debug(" 96s; Initialized %s\n", __func__, pad -> name) ; 

















// 返 回 相应 的 omap_hwmod_mux_info 供 omap_hwmod 使 用 . 


return hmux; 





er: 
kfree( hmux -> pads) ; 
er: 
kfree( hmux) ; 
err : 
pr err(" 96s; Could not allocate device mux entry n" , _ fune. ); 


return NULL; 
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/ * Assumes the calling function takes care of locking * / 

// 该 接口 提供 给 omap_hwmod 驱动 使 用 , “4 omap_hwmod 状态 发 生变 化 时 
// lll enable, idle, shutdown 如 果 此 时 有 pin 设置 需求 ,对 相应 的 pin 进行 设置 
// 时 调用 该 接口 . 

//pad 通过 其 flag 参数 表示 pad 的 当前 状态 . 

void omap_hwmod_mux( struct omap_hwmod_mux_info * hmux, u8 state) 


| 





























int 1; 


for(i20; i < hmux -» nr pads; i++) | 
struct omap. device pad * pad = &hmux -> pads[ i] ; 
int flags, val = — EINVAL; 


// 通 过 flag 表示 pad 当前 的 状态 

//pad 属性 包含 OMAP_DEVICE_PAD_REMUX 时 在 idle 和 disable 
// 状 态 下 的 时 候 才 可 以 配置 相应 的 pad ->idle 和 pad ->off 的 值 
flags = pad —> flags; 


switch( state) | 
case. HWMOD STATE ENABLED: 
if( flags & OMAP DEVICE PAD ENABLED) 
break ; 
// 如 果 是 enable , 则 应 设置 flag 配置 pad -> enable 的 值 
flags | = OMAP DEVICE PAD ENABLED; 
val = pad -> enable; 
pr_debug("%s: Enabling 96s %x\n", _ fune, 
pad -> name, val); 
break ; 
case. HWMOD STATE IDLE: 
if(1 (flags & OMAP. DEVICE PAD REMUX) ) 
break ; 
// WR X idle J} H. OMAP_DEVICE_PAD_REMUX 
// 则 应 设置 flag 配置 pad -> idle 的 值 
flags & = - OMAP DEVICE PAD ENABLED; 
val = pad —> idle; 
pr debug(" 96s; Idling %s %x\n", __func_, 


pad -> name, val); 























break ; 
case. HWMOD STATE DISABLED: 
default ; 
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/ * Use safe mode unless OMAP DEVICE PAD REMUX */ 
// 如 果 OMAP_DEVICE_PAD_REMUX 则 配置 pad — off 的 值 
/和 否则 应 该 设置 为 safemode 
if( flags & OMAP_DEVICE_PAD_REMUX) 

val = pad -> off; 























else 
val = OMAP_MUX_MODE7; 
// 设 置 flag 值 
flags & = - OMAP DEVICE PAD ENABLED; 
pr debug(" 96s; Disabling 96s %x\n", _ fune. , 
pad -> name, val); 


ls 


// 写 pin mux 寄存 器 . 

if(val »20) | 
omap. mux, write( pad -> partition, val, 
pad -> mux —> reg. offset) ; 
pad —> flags = flags; 


| 





从 以 上 分 析 可 见 ，TI 提供 的 引 脚 管理 已 经 包括 了 引 脚 总 的 管理 ， 以 及 专门 针对 设备 模 
块 的 引 脚 管理 ， 其 中 还 涉及 了 电源 管理 相关 的 功能 ， 是 比较 完整 的 架构 。 只 是 完全 基于 TI 
处理 器 的 特点 进行 设计 的 ， 并 没有 考虑 进一步 的 抽象 ， 没 有 将 操作 和 属性 分 别 抽象 出 来 ， 这 























一 点 与 pin control 架构 还 是 有 差别 的 ， 但 是 从 功能 完整 性 的 角度 来 看 已 经 是 完整 的 方案 了 ， 
可 以 帮助 理解 pin control 架构 。 在 设备 模块 引 脚 管理 的 代码 中 可 见 omap_hwmod， 该 结构 是 
所 有 设备 模块 的 抽象 ， 与 系统 管理 以 及 电源 管理 息息相关 ， 该 结构 虽然 与 TI 处 理 器 有 紧密 
关系 ， 但 也 是 非常 清晰 合理 的 上 层 抽 象 ， 所 以 作为 设备 模块 的 资源 之 一 的 引 脚 管理 信息 自然 
应 该 包含 在 其 中 。 对 于 omap_hwmod 相关 的 代码 会 在 TI 的 SoC 电源 管理 部 分 进行 详细 介绍 。 














4.10 小 结 





本 章 主要 涉及 Linux 内 核 核心 功能 。 这 些 功 能 是 内 核 重要 的 横 切 功能 ， 又 











属于 系统 的 底 


层 框架 ， 也 是 与 系统 移植 相关 的 重要 功能 。 总 的 来 说 ， 这 部 分 是 和 芯片 相关 的 底层 核心 功能 





模块 。 








内 核 初始 化 部 分 是 和 系统 中 各 个 模块 部 息息相关 的 ， 也 是 进行 板 级 定制 以 及 系统 移植 的 


重要 部 分 。 











地 址 映射 是 与 内 核 关 系 紧密 的 部 分 ， 毕 兑现 代 人 处理 器 都 是 使 用 的 虚拟 地 址 ， 这 样 在 内 核 
层面 就 需要 地 址 映射 ， 而 对 设备 驱动 首先 要 做 的 就 是 设备 相关 的 寄存 器 映射 ， 可 以 说 地 址 映 








射 是 系统 执行 的 基础 ， 对 地 址 映射 的 理解 体现 了 对 系统 层面 的 整体 把 握 。 
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中 断 处 理 和 内 存 管 理 都 是 Linux 内 核 的 重要 组 成 部 分 ， 中 断 处 理 主 要 涉及 中 断 控 制 器 的 
实现 。 内 存 管理 大 部 分 的 设计 都 是 与 体系 结构 无 关 的 ， 体 系 结构 相关 部 分 大 多 可 以 通过 参数 
设置 完成 。 深 入 了 解 内 存 管 理 对 理解 Linux 内 核 至 关 重 要 ， 相 应 的 参数 设置 对 于 完善 系统 、 
提高 效率 也 是 十 分 有 意义 的 。 

其 他 部 分 如 DMA、 时 钟 管理 、 时 间 管 理 、GPIO 以 及 引 脚 复 用 都 为 系统 提供 了 操作 接 
口 ， 它 们 作为 公共 模块 为 系统 的 其 他 模块 提供 相应 的 服务 。 理 解 这 些 服务 的 框架 就 可 以 更 好 
地 使 用 相关 的 服务 实现 特定 的 功能 。 
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BSE ”内核 设备 管理 以 及 驱动 基础 框 染 


本 章 所 涉及 的 内 容 在 层次 上 基本 属于 桥接 层 、 虚 拟 层 等 上 层 的 框架 及 实现 ， 主 要 介绍 设 
备 管理 和 驱动 相关 的 功能 模块 。 这 些 模块 为 实际 的 设备 管理 和 驱动 提供 基础 框架 和 服务 ， 可 
以 帮助 驱动 程序 的 开发 人 员 开 发 体系 结构 无 关 的 代码 ， 从 而 使 得 驱动 程序 本 身 更 关注 于 设备 
的 操作 而 不 是 关注 包含 处 理 需 体系 结构 在 内 的 整个 系统 。 














5.1 VES 及 其 与 设备 的 关联 


Linux 系统 的 一 个 基本 思想 就 是 “一 切 丝 是 文件 ”， 就 是 说 除了 传统 意义 的 文件 之 外 ， 
目录 、 设 备 等 都 是 以 文件 的 方式 面向 用 户 。 这 一 思想 体现 了 一 种 高 度 抽象 。 这 种 高 度 抽 
象 对 使 用 者 来 说 代表 了 统一 的 操作 界面 ， 有 了 统一 的 界面 ， 应 用 就 可 以 将 关注 点 放 在 数 
据 处 理 本 身 ， 而 不 是 获得 数据 的 操作 方法 上 。 

在 Linux 系统 中 ， 实 现 “ 一 切 丝 是 文件 ”的 模块 就 是 VFS (Virtual File System) 。 要 实 
现 该 功能 ， 需 要 在 框架 层 进行 高 级 抽象 ,不仅 要 考虑 文件 ， 还 要 对 文件 有 一 个 统一 的 组 织 视 
fa, 不 仅 要 有 各 种 文件 ， 还 要 让 应 用 能 够 按照 一 定 的 方式 和 人 逻辑 找到 文件 。 文 件 组 织 的 规范 
是 在 FHS (文件 系统 层次 规范 ) 中 进行 说 明 ， 由 于 属于 上 层 系统 的 规范 ， 就 不 进行 详 述 了 ， 
但 是 要 明确 文件 的 组 织 方式 是 非常 重要 的 。 

谈 到 虚拟 文件 系统 要 考虑 实际 的 文件 系统 ， 实 际 的 文件 系统 就 是 虚拟 文件 系统 的 实例 
化 。 虚 拟 文件 系统 将 文件 系统 管理 的 实体 以 及 管理 的 操作 进行 抽象 ， 而 实际 的 文件 系统 就 将 
这 些 抽象 实例 化 ， 这 就 要 求 VFS 本 身 还 要 对 实际 文件 系统 的 管理 实体 进行 管理 。 

最 后 要 明确 VES 的 用 户 是 谁 ? 是 应 用 程序 也 是 用 户 层 的 进程 。 这 一 点 明确 了 ， 才 更 容 
易 理 解 VFS, 


























5.1.1 VFS 框架 


VFS 的 实现 是 以 “一 切 缘 是 文件 ”为 需求 出 发 点 的 。 要 理解 VFS 的 框架 首先 看 一 下 
VFS 和 系统 的 静态 关系 框图 ， 如 图 5-1 所 示 。 

从 图 5-1 可 见 ，VFS 是 用 户 层 的 直接 接口 ， 是 面向 用 户 的 服务 。 其 封装 了 不 同文 件 系 
统 的 差异 ， 这 样 用 户 只 把 注意 力 集中 在 VES 中 即 可 。 在 VES 中 有 dcache 和 inode cache, iX 
两 部 分 是 两 种 管理 实体 的 kmem_cache cache 中 分 别 存 放 着 管理 实体 dentry (directory entry ) 
和 inode (index node) 。 这 两 种 管理 实体 分 别 代表 文件 管理 的 两 个 重要 方面 ， 一 方面 是 文件 
组 织 管理 ， 另 一 方面 是 物理 文件 管理 ， 包 括 元 数据 管理 (包括 时 间 、 权 限 等 ) 、 文 件数 据 管 
理 以 及 相关 的 操作 管理 。 

1. 文件 组 织 管理 

VES 中 dentry 代表 文件 组 织 的 管理 实体 ， 能 够 通过 它 以 树 状 结构 来 对 各 种 类 型 的 文件 进 
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图 5-1 VFS 和 系统 静态 关系 图 


Hardware 


行 管理 ， 其 中 树 状 结构 的 根 是 通过 d_alloc_root 进行 分 配 的 。 注 意 这 里 说 的 是 树 状 结构 而 不 
是 目录 结构 ， 树 状 结构 只 是 表示 组 织 形 式 ， 而 目录 结构 容易 和 目录 文件 混 清 从 而 产生 歧义 。 
dentry 表示 系统 运行 时 文件 的 组 织 ， 文 件 的 组 织 是 以 文件 名 及 层次 的 方式 实现 的 ， 先 看 看 
Linux 系统 是 如 何 组 织 这 些 文件 的 (要 符合 FHS 标准 ) ， 如 图 5-2 所 示 。 

在 图 5-2 中 每 个 节点 被 使 用 时 都 会 在 VFS 层 中 创建 dentry， 这 样 可 以 快速 通过 文件 名 进 
行 查 找 和 定位 ，Linux 内 核 中 对 dentry 的 管理 组 织 形式 如 图 5-3 所 示 。 

dentry 的 d_subdirs 字段 指向 子 目 录 项 的 第 一 个 元 素 ， 子 目录 项 之 间 通 过 d child 相互 链 
接 。dentry 的 d. parent 字段 指向 目录 项 的 父 目 录 项 ， 如 果 是 文件 系统 的 根 ， 则 指 回 自己 。 这 
些 属性 就 可 以 建立 文件 的 树 状 层次 组 织 管 理 结 构 ; dentry_hashtable 和 d. hash 则 是 为 了 能 
加 速 文件 的 查找 ， 另 外 dentry 作为 动态 资源 也 是 需要 管理 的 ， 相 应 的 管理 算法 由 dentry_un- 
used 组 成 的 链表 进行 管理 ， 在 必要 的 时 候 进 行 资源 释放 。 这 样 在 功能 、 性 能 资源 各 方面 都 
对 文件 名 组 织 进 行 了 管理 。 

仅 有 组 织 的 管理 是 不 够 的 ， 还 要 能 通过 文件 名 访问 其 中 的 数据 。 来 看 看 dentry 数据 结 
构 的 内 容 ， 明 确 如 何 从 组 织 转 到 具体 的 文件 以 及 其 他 的 管理 。 















































293 































































































































































































































































































j "up. cid * SUERTE 
EXE aye 核心 档案 Cvmlinuz) 开机 设 定 档 相关 
| boot | 
d 类 似 /dev/null 与 各 种 软件 与 系统 的 设 各 种 软件 的 启动 脚本 
/dev/sda 等 装置 档案 定 档 (scripts ) 
etc [init] 
各 使 用 者 家 目录 ， 每 EO NEU 各 不 同 版 本 核心 的 模 
a 
如 cdrom、floppy 等 暂 
[media | os 
X11R6 
| mt | 
bin 
第 三 方 协力 软件 
记忆 体 让 的 资料， -— 
Ww 资料 ， 如 
核心 、 程 序 等 而 
| we | 开机 或 单 人 维护 模式 jm 
还 能 操作 的 系统 指令 
| sbn | 
网 络 服务 所 提供 的 资 sbin 
srv 料 放置 处 lock mqueue 
记忆 体 中 的 资料 ， 如 share 
sys 核心 、 档 案 系统 等 log | Ipd | 
SIC 
[ mp ] Spool 
var 
图 $-2 Linux 文件 组 织 层 次 
d_subdirs « 
MÀ d hash 
d parent d parent d parent 
—» dentry unused «4— — —» d lru «—» d Iru M——P d Iru «— 
d subdirs d subdirs d subdirs 
d child «—» d child IK«—» d child «— — 
r3» d hash > d_hash }<—_> d_hash 
d_alias d_alias d_alias 
dentry_hashtable i i i 
hlist head hlist head | | eee hlist_head hlist_head 


294 























图 5-3 VFS J& dentry 


管理 组 织 形 式 








struct dentry | 
atomic_t d_count; 
unsigned int d flags; / * protected by d. lock * 
spinlock t d lock; / * per dentry lock * / 


int d mounted ; 


i 


struct inode * d_inode; / * Where the name belongs to - NULL is 


* negative * / 


/o* 


* The next three fields are touched by __d_lookup. Place them here 


* so they all fit in a cache line. 


*/ 
struct hlist node d. hash ; / * lookup hash list * / 
struct dentry * d parent; / * parent directory * / 


struct qstr d_name; 


struct list_head d_lru; / * LRU list * / 
/ox 
* d child and d, rcu can share memory 
*/ 
union | 
struct list head d. child; / * child of parent list ** / 
struct rcu, head d, rcu; 
| d_u; 
struct list head d_subdirs ; /** our children * / 
struct list head d alias; / * inode alias list * / 
unsigned long d_time; / * used by d_revalidate * / 


const struct dentry operations * d op; 
struct super block * d sb; / * The root of the dentry 
void * d fsdata; / * fs- specific data ** / 








// 当 文件 名 较 短 时 使 用 此 区 域 加 速 访问 


tree */ 


unsigned char d_iname[ DNAME_INLINE_LEN_MIN | ; / * small names * / 


5 











在 dentry 结构 中 除了 之 前 介绍 的 与 组 织 管理 相关 的 属性 外 ， 还 有 一 些 比较 重要 的 属性 ， 分 别 
如 下 : 


e d_inode 指向 inode 实体 的 指针 ，inode 表示 文件 的 具体 属 

e d name 表示 文件 的 名 字 。qstr 是 quick string 的 缩写 包含 
里 用 它 是 对 文件 名 进行 封装 以 便 进 行 快速 查找 。 如 果 文 
hash 值 会 很 费时 ， 这 里 可 以 空间 换 时 间 。 
































© d op 是 对 文件 名 的 一 些 计算 和 操作 接口 。VFS 针对 通常 





性 。 
字符 串 、 长 度 和 hash 值 ， 这 
件 名 很 长 ， 通 过 文件 名 计算 








的 文件 名 操作 已 经 提供 了 基 


本 的 接口 ， 但 是 对 特定 的 文件 系统 ， 标 准 的 操作 是 不 能 满足 需要 的 。 如 fat32 文件 系 
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统 对 文件 名 不 区 分 大 小 写 ， 这 时 进行 文件 名 比较 就 需要 特定 的 操作 接口 。 在 VES 中 
定义 dentry_operations 相关 接口 ， 具 体 文件 系统 根据 需要 对 文件 名 的 操作 进行 重 定义 
来 满足 文件 系统 自身 的 需要 。 
© d sb 指向 dentry 对 象 所 在 文件 系统 super block 的 实体 。 为 什么 需要 该 指针 呢 ? 因为 在 
Linux 系统 中 ， 对 用 户 来 说 ， 文 件 组 织 整 个 是 一 棵 树 。 但 实际 情况 是 在 这 一 棵 树 上 挂 
载 了 不 同 的 文件 系统 ， 而 每 个 文件 系统 本 身 就 是 一 棵 树 ， 所 以 表示 文件 名 的 管理 实体 
dentry 同样 应 该 和 所 在 的 文件 系统 ( 子 树 ) 关联 (通过 该 指针 实现 ) 。 用 户 看 到 的 树 
是 多 个 文件 系统 子 树 拟 合 形成 的 ， 拟 合 的 过 程 涉及 挂 载 点 ， 由 d mounted 表示 是 否 为 
挂 载 点 ， 这 样 可 以 在 文件 名 的 层次 上 关联 文件 系统 的 挂 载 。 实 际 挂 载 的 管理 将 在 后 续 
介绍 。 
以 上 是 系统 运行 时 VFS 对 文件 名 的 组 织 管理 ， 这 是 VES 管理 的 一 个 方面 。 把 文件 名 和 
物理 文件 管理 分 离 ， 这 样 在 VFS 层 就 很 容易 实现 符号 文件 的 快速 定位 。 
2. 物理 文件 管理 
VES 管理 的 另 一 方面 是 系统 运行 时 对 物理 文件 的 管理 。 相 应 的 管理 实体 是 inode。 注 意 
inode 是 VFS 层 对 物理 文件 的 管理 实体 ， 主 要 由 于 VFS 是 抽象 文件 系统 ， 其 中 的 管理 实体 应 
该 是 抽象 的 概念 ， 而 inode 在 VFS 中 代表 物理 文件 。 这 就 有 些 奇 怪 了 ， 如 何 做 到 抽象 概念 到 
物理 概念 的 转换 呢 ? 了 解 了 其 中 的 过 程 就 明确 了 如 何 从 VES 过 渡 到 实际 文件 系统 ， 可 以 说 
inode 是 抽象 文件 系统 VES 到 物理 文件 系统 的 关键 点 。 在 面向 对 象 的 设计 中 通常 通过 继承 关 
系 表示 具体 实例 化 ，C 语言 则 是 通过 包含 方式 来 实现 实例 化 ， 以 ext2 文件 系统 为 例 : 





























struct ext2_inode_info | 
. le32 idata[ 15]; 
_u32 i flags; 

. u32 i faddr; 

_u8 . i frag no; 

. u8 l1 frag size; 

. ul6 i state; 

. u32 i file acl; 

— u32 i dir acl; 


. u32 i dtime; 


struct mutex truncate mutex; 
struct inode vfs inode; 


struct list head i_orphan; / * unlinked but open inodes * / 


ls 





其 中 包含 VFS 的 inode Hl vfs_inode， 之 前 提 到 的 VFS inode cache 实际 是 各 个 具体 文件 
系统 inode_info 的 cache， 如 ext2 就 是 ext2_inode_info 的 kmem_cache。 在 VFS 中 ， 对 物理 
文件 进行 管理 的 实体 在 运行 中 的 数据 会 直接 对 应 到 具体 文件 系统 的 物理 文件 管理 实体 ， 
而 inode 是 从 各 种 文件 系统 物理 文件 管理 中 抽象 出 来 的 属性 集合 ， 注 意 这 些 都 是 运行 时 的 
信息 。 要 了 解 如 何 从 inode 转换 到 具体 的 文件 系统 操作 ， 首 先 需要 看 看 inode 的 具体 内 容 : 
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struct inode | 


struct hlist_node i_hash; 

struct list_head i_wb_list; / * backing dev IO list */ 
struct list_head i_lru; / * inode LRU list * / 
struct list_head i_sb_list; 

struct list_head i dentry; 

unsigned long 1 ino; 

atomic t 1 count; 

unsigned int i nlink; 

uid t i uid; 

gid t i gid; 

dev. t i rdev; 

unsigned int i blkbits ; 


u64i version; 


loff t i size; 

struct timespec 1 atime; 

struct timespec 1 mtime; 

struct timespec 1 ctime; 

blkent_t i_blocks; 

unsigned short i bytes; 

umode t i mode; 

spinlock t i lock; / * i blocks, i bytes, maybe i size */ 
struct mutex 1 mutex; 

struct rw. semaphore i alloc. sem; 


const struct inode operations — *i op; 


const struct file operations * i fop; / * former —»i op —» default file ops **/ 
struct super. block *j sb; 
struct file lock * i. flock; 
struct address space * i mapping; 
struct address, space i data; 
struct list. head i devices; 
union | 
struct pipe. inode, info * i pipe; 
struct block. device * i bdev; 
struct cdev * i_cdev; 
js 
. u32 1 generation; 
unsigned long i state; 
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unsigned long dirtied_when; / * jiffies of first dirtying * / 


unsigned int i flags; 
atomic t 1 writecount ; 
void * j private; / * fs or device private pointer * / 


bs 


从 内 容 可 见 inode 包含 大 量 的 信息 。 

首先 类 似 于 dentry， 通 过 链表 在 VFS 层 中 对 inode 完成 各 种 不 同 的 分 类 管理 。 对 文件 的 
最 后 访问 时 间 、 最 后 修改 时 间 和 最 后 修改 inode 的 时 间 分 别 由 i_atime、i_mtime Fi i_ctime 进 
行 管理 。 文 件 大 小 相关 信息 由 i_size 和 i_blocks 表示 。 使 用 两 种 表现 方式 是 因为 文件 系统 的 
物理 内 容 通常 保存 在 块 设备 中 ， 所 以 分 别 通过 字 节 大 小 和 所 占 块 数 表示 文件 的 大 小 ， 以 方便 
进行 操作 。i_rdev 表示 文件 所 在 实际 的 设备 号 (如 果 是 设备 则 是 设备 号 ) 。 另 外 inode 中 还 
通过 i_mode 体现 了 “一 切 缘 是 文件 ”。 其 中 可 以 表示 特殊 的 文件 ， 也 可 通过 以 下 的 宏 表 示 
不 同类 型 的 文件 。 




































































"define S_IFSOCK 0140000 
#define S_IFLNK 0120000 
#define S_IFREG 0100000 
#define S_IFBLK 0060000 
"define S_IFDIR 0040000 
#define S_IFCHR 0020000 
#define S IFIFO 0010000 




















如 果 inode 表示 设备 ， 还 可 以 通过 union 中 的 具体 设备 指针 直接 关联 到 设备 的 结构 ，i_ 
devices 会 和 设备 管理 实体 cdev 或 者 bdev 关联 。 

在 关联 到 具体 的 文件 系统 操作 方面 就 要 依靠 操作 接口 。inode 中 有 i_op 和 i_fop 两 种 操 
作 接 口 ， 前 者 主要 是 面向 文件 的 元 数据 及 与 inode 相关 的 特殊 操作 ， 后 者 则 面向 文件 中 数据 
的 操作 ， 通 过 这 些 操作 接口 的 重 定向 就 可 以 转向 实际 的 文件 系统 的 操作 ， 另 外 由 于 文件 可 以 
mapping 到 虚拟 地 址 空间 ， 也 需要 转换 到 具体 文件 系统 给 定 的 操作 中 ， 这 个 转换 由 i mapping 
中 相关 的 操作 接口 完成 ，VFS 还 为 mapping 的 方式 设计 了 direct IO 框架， 以便 进行 相关 的 操 
作 ， 这 样 就 与 buffer 以 及 page cache 直接 关联 起 来 。 

这 样 整个 系统 就 完成 了 虚拟 文件 系统 和 实际 文件 系统 的 转换 ， 这 几 种 重要 的 数据 结构 已 
在 VES 中 进行 介绍 ， 所 以 不 再 对 实际 的 文件 系统 进行 详 述 ， 实 际 文件 系统 主要 是 对 块 设备 
的 空间 进行 组 织 和 管理 以 存放 实际 的 数据 。 

看 了 这 么 多 ， 都 还 是 在 VFS 层 的 管理 实体 ， 并 没有 见 到 如 何 从 进程 角度 理解 文件 并 和 
VFS 相关 实体 进行 关联 ， 这 些 都 属于 系统 运行 时 的 状态 信息 。 其 关联 如 图 5-4 所 示 。 


Id 
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User space 







file table 1 


struct file 


struct file 


Kernel space 






Open files to same link 


Links to same file 






struct dentry 
图 5-4 VFS 和 进程 动态 关联 图 


从 图 5-4 可 见 ， 在 用 户 进 程 中 文件 就 是 file 结构 体 ， 该 结构 会 在 文件 打开 时 创建 。 下 面 
来 看 看 其 主要 内 容 : 


struct file | 
/* 
* fu_list becomes invalid after file_free is called and queued via 
* fu_rcuhead for RCU freeing 
*/ 
union | 


struct list_head fu_list; 


struct rcu, head fu, reuhead ; 
j fons 
struct path f path; 
#define f. dentry f path. dentry 
#define f. vfsmnt f path. mnt 
const struct file operations * f op; 
spinlock_t f_lock; / * f ep links, f flags, no IRQ */ 
atomic, long t f count; 
unsigned int f flags; 
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fmode_t f_mode; 
loff_t f_pos; 
struct fown, struct f owner; 
const struct cred * f. cred; 


struct file ra, statd ra; 


u64 f version; 


/ * needed for tty driver, and maybe others * / 


void * private, data; 


E 








注意 这 里 通过 path 结构 表示 路 径 (path 结构 中 dentry 表示 所 在 子 树 的 文件 层次 属性 ， 
mnt 表示 整体 文件 树 的 层次 ) ，path 中 的 dentry 可 与 物理 文件 的 管理 实体 inode 关联 起 来 。 为 
了 方便 文件 内 容 的 操作 ，file 中 的 人 op inode 中 的 了 f -op 有 关联 ， 但 不 一 定 相 同 ， 这 样 可 以 
按 需 变化 ， 提 高 系统 的 灵活 性 ， 后 续 介 绍 设备 的 时 候 再 进行 详细 介绍 。 

3. VFS 与 进程 关联 

从 整体 上 看 看 系统 是 如 何 将 VES 内 部 以 及 和 进程 进行 关联 的 ， 细 节 如 图 5-5 所 示 。 


一 vismount file_system_type 



































mnt-instances EE . super_block 








mnt-sb > vfsmount list « fs_supers 







































































mnt-devname s mounts 
mnt owner s list K——»,| super blocks 
T mnt-list 
m> mnt namespace mnt-child 
count mnt-mounts s dirty 
root mnt parent 
list «— mnt clash 
mnt root 














mnt mountpoint 1 


















































































































































































































































task struct mount in 
>| fs struct Sp agne 
namespace oe » dentry 
erect d_vismnt 
fs root/pwd/altroot. d sb 
files d inode ~ y inode m —>| inode_operations 
d_ailas }¢—, inode dentry list «——— i_dentry e 
d parent i nlink 
files struct file d child i sb 
t list as (aly busts 
fd f dentry d iru i no 
d hash 
f vfsmnt = 
= dentry operatio 5 
Top d_op m d i op 
d time dhash() i_fop 
e d revalidate() 
d name e 
d_iname d compare() 


























files operations 








图 5-5 VFS 和 进程 数据 结构 关系 图 
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图 5-5 中 还 有 一 些 数据 结构 没有 说 明 。mnt_namespace 可 以 实现 用 户 文件 系统 的 虚拟 化 
管理 ; vfsmount 则 是 用 来 管理 文件 系统 的 挂 载 ， 之 前 见 到 的 path 就 是 通过 vfsmount 将 不 同 的 
文件 系统 子 树 拟 合成 用 户 所 见 的 文件 路 径 。 挂 载 同样 是 有 层次 的 ， 相 应 的 层次 关系 由 vfs- 
mount 的 链表 以 及 与 文件 层次 管理 dentry 的 关联 来 完成 ， 具 体 到 属性 就 是 mnt. parent 表示 挂 
载 的 层次 ; mnt_mountpoint 表示 挂 载 的 上 层 文件 系统 中 的 目录 文件 dentry; mnt_root 表示 挂 
载 的 文件 系统 的 根 目录 文件 dentry， 男 外 对 于 上 层 的 vfsmount 会 通过 其 链表 mnt_mounts 与 下 
J& vfsmount 的 mnt. child 进行 关联 ， 这 样 文件 系统 挂 载 的 整个 层次 就 形成 了 。 

以 一 个 例子 来 理解 文件 树 状 组 织 在 内 核 中 是 如 何 体现 的 。 要 形成 如 图 5-6 所 示 的 文件 
层次 。 

















r1 
















































































\ 
x 
r2 
C d 























图 5-6 XRRR M 


图 5-6 中 可 见 有 两 个 文件 系统 ， 一 个 作为 根 挂 载 到 rl 目录 文件 ， 另 一 个 挂 载 到 文件 系 
统 的 b 目录 文件 上 ，g 文件 并 没有 实际 的 打开 过 。 对 应 的 dentry 实际 情况 如 图 5-7 所 示 。 对 
应 的 vfsmount 实际 情况 如 图 5-8 所 示 。 从 图 5-7 可 见 g 没有 被 访问 所 以 并 没有 g 文件 对 应 的 
dentry， 这 正 说 明 相 关内 容 都 是 当前 系统 运行 状态 的 体现 。 

有 了 以 上 的 示例 ， 基 本 可 以 理解 文件 层次 在 内 核 运 行 状态 下 如 何 表示 了 。 

4. 具体 文件 系统 管理 

剩 下 的 还 有 就 是 对 具体 文件 系统 的 管理 ， 在 VFS 中 同样 要 对 具体 的 文件 系统 进行 管理 ， 
相应 的 有 file_system_type 和 super_block ， 前 者 管理 的 是 内 核 中 注册 的 所 有 文件 系统 ， 后 者 主 
要 是 管理 文件 系统 的 元 数据 (包括 实际 设备 以 及 块 设备 组 织 的 元 信息 等 ) 和 文件 系统 通过 
元 数据 管理 文件 的 操作 接口 。 这 些 都 与 具体 的 文件 系统 关系 紧密 就 不 进行 详 述 。 
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图 5-7 示例 文件 层次 dentry 实际 表示 
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图 5-8 示例 文件 层次 vfsmount 实际 表示 
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5. VFS 操作 的 用 户 通知 








文件 作为 用 户 的 接口 ， 除 了 具体 的 操作 功能 之 外 ， 操 作 本 身 也 是 用 户 关心 的 一 个 方面 ， 这 
就 需要 内 核能 够 提供 对 文件 进行 相关 操作 的 通知 ， 这 些 通知 直接 般 入 到 VES 文件 操作 接口 中 
即 可 ， 相 当 于 监测 统计 点 ， 这 也 是 VFS 提供 的 功能 ， 这 些 监测 统计 通过 fsnotify_xxx 上 报 给 事 
件 管 理 模块 inotify ， 而 inotify 负责 管理 用 户 的 监测 i 青 求 并 通知 用 户 ， 内 核 提供 监测 接口 如 下 : 




















© fsnotify_move 文件 从 一 个 目录 移动 到 另 一 个 目录 。 
® fsnotify_nameremove 文件 从 目录 中 删除 

® fsnotify_inoderemove 自 删 除 。 

© fsnotify_create 创建 新 文件 。 

e fsnotify_mkdir 创建 新 目录 。 

e fsnotify_access 文件 读 。 

e fsnotify_modify 文件 写 。 

e fsnotify_open 文件 打开 。 

© fsnotify_close 文件 关闭 。 

e fsnotify_xattr 文件 的 扩展 属性 被 修改 。 

e fsnotify_change 文件 被 修改 或 原 数据 被 修改 。 
内 核 会 将 如 下 的 事件 上 报应 用 层 : 


#define ALL_FSNOTIFY_EVENTS(FS_ACCESS | FS MODIFY | FS ATTRIB | | 
FS CLOSE WRITE | FS CLOSE NOWRITE | FS OPEN | | 
FS MOVED FROM | FS MOVED TO | FS CREATE | \ 
FS DELETE | FS DELETE SELF | FS MOVE SELF | \ 
FS UNMOUNT | FS Q OVERFLOW | FS IN IGNORED | \ 





FS OPEN PERM | FS ACCESS PERM | FS EXCL UNLINK | | 


FS ISDIR | FS IN ONESHOT | FS DN RENAME | \ 
FS DN MULTISHOT | FS EVENT ON CHILD) 


应 用 程序 可 以 通过 inotify 接口 进行 所 关心 文件 的 监测 。inotify 属于 应 用 层 的 内 容 ， 


进行 详 述 了 。 
至 此 整体 上 在 VFS 层 为 用 户 提供 的 各 种 功能 都 进行 了 框架 分 析 和 总 结 。 


5.1.2 VFS 与 设备 关联 





就 不 


由 于 VFS 是 “一 切 缘 是 文件 ”的 实现 者 ， 设 备 作为 特殊 的 文件 统一 与 VFS 有 关联 ， 理 


解 这 do Oa 过 统一 的 接口 来 对 设备 进行 操作 。 








首先 ，VFS 层 通过 init_special_inode 为 设备 特殊 文件 提供 了 操作 接口 ， 具 体内 容 如 下 : 





void init_special_inode( struct inode * inode, umode_t mode, dev_t rdev) 
| 
inode —» i mode = mode; 
if(S ISCHR( mode) ) | 
inode —> i fop = &def chr fops; 


inode —» i_rdev = rdev; 
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| else if( S ISBLK( mode) ) | 
inode —> i fop = &def blk fops; 
inode -> i_rdev = rdev; 
| else if(S_ISFIFO( mode) ) 
inode —> i. fop = &def fifo fops; 
else if( S ISSOCK( mode) ) 
inode —» i. fop = &bad. sock. fops; 
else 
printk( KERN |. DEBUG " init, special inode; bogus i mode( 960) for" 
" inode 96s:;96luYn" , mode, inode ->i sb -> s id, 
inode —» i, ino) ; 


| 


正如 之 前 所 述 由 inode 中 的 i_mode 来 进行 设备 特殊 文件 的 设 定 。 相 应 的 i_fop 对 应 的 def 
chr. fops def. blk. fops 分 别 是 字符 设备 和 块 设备 在 设备 文件 打开 时 进行 操作 的 接口 ， 属 于 上 层 的 
抽象 操作 。 其 中 会 根据 设备 号 等 细节 选择 合适 的 设备 接口 进行 操作 ， 细 节 会 在 介绍 相应 设备 时 详 
述 。 实 际 的 设备 号 则 保存 在 i_rdev 中 。 这 样 VES 中 文件 的 管理 实体 inode 就 和 设备 关联 了 。 

具体 文件 系统 会 有 两 部 分 操作 与 设备 文件 相关 ， 分 别 是 创建 时 和 打开 时 。 创 建 时 是 
由 具体 文件 系统 的 mknod 进行 操作 ， 打 开 时 会 获得 inode (需要 检查 属性 是 否 为 设备 文 
件 ) ， 这 两 部 分 都 会 在 需要 的 时 候 调 用 init_special_inode， 这 样 整个 系统 就 可 以 将 设备 统 
一 的 作为 文件 来 看 待 ， 少 量 的 局 部 特殊 操作 带 来 全 局 统一 的 接口 ， 其 设计 与 实现 还 是 十 
分 巧妙 的 。 
























































5.2 Linux 设备 模型 ( Linux device model) 


5.2.1 设备 模型 的 需求 及 基本 设计 


设备 可 以 说 是 在 内 核 管理 中 最 具 复 杂 性 和 多 样 性 的 部 分 ， 如 图 5-9 所 示 。 从 图 5-9 可 
见 ， 设 备 类 型 如 此 繁杂 ， 需 要 管理 各 种 不 同 并 且 差 异 极 大 的 设备 ， 在 系统 层面 又 要 对 它们 进 
行 统一 管理 ， 实 现 难度 非常 大 。 主 要 的 难度 体现 在 既 要 适应 这 些 多 样 性 还 要 提供 统一 的 视角 
来 进行 管理 。 

设备 管理 要 对 各 种 不 同 设备 进行 生命 周期 管理 、 电 源 管理 、 设 备 发 现 以 及 驱动 动态 绑 定 和 
管理 ， 这 就 要 求 有 一 个 良好 的 模型 对 不 同 的 设备 在 各 个 层面 进行 管理 。 这 些 是 针对 设备 模型 ， 
在 内 核 内 部 资源 管理 方面 提出 的 需求 。 另 外 一 个 重要 的 需求 是 站 在 用 户 的 角度 ， 和 希望 设备 模型 
能 够 提供 给 用 户 一 个 框架 ,通过 该 框架 用 户 可 以 方便 地 观察 设备 状态 和 设置 设备 属性 。 

l. 物理 设备 管理 的 整体 抽象 模型 

先 来 看 看 设备 模型 如 何 满足 物理 设备 管理 的 需求 ， 在 介绍 硬件 的 时 候 可 以 看 到 很 多 物理 
设备 都 是 挂 在 物理 总 线 上 的 ， 而 处 理 器 内 部 特别 是 SoC 内 部 的 设备 虽然 有 片 内 总 线 ， 但 是 片 
内 总 线 是 硬件 逻辑 并 没有 软件 抽象 的 管理 实体 ， 这 样 内 部 的 设备 就 显得 散乱 ， 为 了 完成 以 上 
的 管理 需求 ， 内 核 将 整个 系统 的 物理 设备 进行 了 一 定 的 抽象 组 织 ， 形 成 了 抽象 总 线 加 物理 总 
了 04 
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图 $-9 Linux 内 核 设 备 复杂 多 样 性 
线 的 框架 结构 如 图 5-10 所 示 。 
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图 5-10 设备 模型 的 抽象 组 织 
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从 图 5-10 可 见 ， 设 备 模型 通过 抽象 的 platform bus 将 与 处 理 器 联系 紧密 ( 片 内 设备 ) 
但 逻辑 并 不 相关 的 物理 设备 组 织 在 一 起 ， 这 样 从 整体 上 整个 物理 系统 就 形成 了 总 线 加 设备 的 
组 织 结构 。 另 外 由 于 设备 是 需要 相应 地 操作 才能 工作 ， 需 要 将 这 些 操作 抽象 成 为 设备 驱动 。 
对 整个 物理 设备 系统 进行 总 结 ， 只 需要 总 线 、 设 备 驱动 和 设备 三 个 管理 实体 就 可 以 完成 管理 
物理 设备 的 需求 ， 这 些 总 线 上 的 物理 设备 相应 的 生命 周期 、 驱 动 绑 定 以 及 管理 就 可 以 通过 总 
线 来 完成 。 

在 介绍 设备 分 类 的 时 候 ， 将 设备 分 为 功能 型 设备 和 总 线 型 设备 ， 这 里 看 到 的 模型 是 通过 
总 线 管 理 各 种 物理 设备 ， 但 是 此 模型 并 没有 完全 站 在 用 户 使 用 的 视角 考虑 ， 用 户 的 视角 更 关 
心 的 是 设备 的 功能 ， 所 以 同样 需要 进行 功能 型 设备 的 管理 ， 虽 然 在 物理 上 它们 是 一 个 设备 ， 
但 是 逻辑 上 应 该 分 开 管理 (逻辑 功能 设备 会 和 物理 设备 关联 ) ， 于 是 将 功能 型 设备 的 管理 放 
入 功能 框架 中 进行 就 显得 比较 合理 ， 只 是 要 与 设备 模型 框架 进行 交互 。 

2. 观察 、 设 置 和 管理 设备 的 解决 方案 

对 用 户 从 各 种 角度 方便 地 观察 和 设置 设备 的 需求 ， 最 好 采用 Linux 统一 的 方式 一 一 文件 
系统 ， 内 核 针 对 性 的 设计 了 sys 文件 系统 框架 来 满足 这 些 需求 。 整 个 sys 系统 框架 如 图 5-11 
所 示 。 











kernel devices 


platform 


drviers devices 








dimer mE dmtiner.0 mcspi.0 i2c.0 














Kk 5-11 sys 文件 系统 组 织 


从 图 $-11 可 见 ，sys 文件 系统 提供 了 总 线 (bus) 管理 的 视角 和 功能 分 类 (class) 管理 
的 视角 ， 另 外 还 提供 了 整体 的 电源 管理 以 及 系统 参数 的 设置 。 

内 核 中 数据 结构 与 sys 文件 系统 关系 如 图 5-12 所 示 。 

从 图 5-12 可 见 ， 实 际 的 设备 和 驱动 是 通过 kobject 来 进行 管理 的 ， 而 上 层 的 kset 和 sub- 
system 更 多 是 用 来 组 织 相关 的 底层 设备 模型 中 的 设备 和 驱动 ， 而 最 下 层 的 attribute (属性 ) 
是 与 设备 和 驱动 等 相关 的 实体 表示 为 sys 文件 系统 的 文件 。 
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5-12 sys 文件 系统 与 数据 结构 关系 
先 来 看 看 重要 的 数据 结构 kobject， 其 内 容 如 下 : 





struct kobject | 


const char * name; 
struct list_head entry; 
struct kobject * parent; 
struct kset * kset; 
struct kobj_type * ktype; 
struct sysfs_dirent * sd; 
struct kref kref; 


unsigned int state_initialized;1; 

unsigned int state in, sysfs:1; 

unsigned int state add, uevent sent;1; 
unsigned int state remove, uevent, sent :1; 


unsigned int uevent. suppress :1 ; 


E 








kobject 承担 了 两 部 分 的 管理 功能 。 其 一 是 通过 kref 承担 了 生命 周期 管理 (通过 引用 计 
数 实 现 ) 功能 ，kobject 是 高 度 的 抽象 实体 ， 对 具体 的 实体 (注意 这 些 实体 可 以 不 是 设备 或 
者 驱动 ， 而 是 一 些 模块 属性 ) 生命 周期 的 状态 和 管理 则 通过 内 和 骨 kobject 来 完成 ， 这 样 需要 
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抽象 的 kobject 到 具体 实体 的 转换 ， 这 种 转换 通过 ktype 来 实现 ， 转 换 通 常 是 在 具体 的 实体 释 
放 以 及 sys 文件 系统 的 操作 中 需要 。 
针对 这 些 功能 ， 内 核 提 供 了 一 系列 接口 进行 相关 操作 ， 首 先是 引用 计数 的 接口 ， 具 体 如 下 : 














void kref_init( struct kref * kref) ; 
void kref get(struct kref * kref) ; 


int kref. put( struct kref * kref, void( * release) (struct kref * kref) ) ; 





这 些 接口 主 要 是 针对 引用 计数 的 增 减 进行 操作 ，release 中 可 以 进行 抽象 到 具体 的 转换 ， 
相应 的 允许 内 核 除 kobject 之 外 包含 kref 的 实体 ， 进 行 生 命 周期 的 管理 。 
对 设备 模型 中 的 kobject 内 核 提 供 如 下 的 接口 进行 生命 周期 的 管理 . 








extern struct kobject * kobject_get(struct kobject * kobj) ; 


extern void kobject_put(struct kobject * kobj) ; 
下 面 以 kobject_put 为 例 看 一 下 是 如 何 实现 的 : 


void kobject_put(struct kobject * kobj) 
| 
if(kobj) | 
if( ! kobj -> state, initialized ) 
WARN(1, KERN WARNING "kobject;' 968 (906p): is not " 
"initialized, yet kobject_put() is being " 
"called. Xn" , kobject_name(kobj) , kobj) ; 
kref_put( &kobj -> kref, kobject, release) ; 


| 





可 见 其 就 是 使 用 kref 的 接口 进行 ， 其 中 有 相对 于 kref 具体 的 转换 接口 kobject_release。 
kobject_release 中 会 调用 kobject_cleanup ， 下 面 来 看 看 kobject_cleanup 的 具体 实现 : 


static void kobject_cleanup( struct kobject * kobj ) 


| 














// 通 过 kobj_type 进行 具体 的 实例 形态 的 转换 
struct kobj_type * t = get_ktype(kobj) ; 


const char * name = kobj -> name; 


pr_debug("kobject:' 968 (%p): %s\n", 
kobject name(kobj), kobj, __func__) ; 


// 没 有 进行 实体 的 实例 化 需要 报错 
if(t && ! t-> release) 
pr_debug("kobject:' 968 (%p): does not have a release( ) " 
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"function, it is broken and must be fixed. \n" , 


kobject_name(kobj) , kobj) ; 


/ * send "remove" if the caller did not do it but sent "add" * / 
// 如 果 状 态 是 发 送 了 add 事件 没有 发 送 remove 事件 就 发 送 remove 事件 通知 


if( kobj -> state_add_uevent_sent && | kobj -> state remove, uevent sent) | 














pr debug("kobject;' 968 (96p): auto cleanup remove event n" , 
kobject, name( kobj) , kobj) ; 
kobject_uevent(kobj, KOBJ. REMOVE) ; 


/ * remove from sysfs if the caller did not do it * / 
// f£ sys 文件 系统 中 实体 还 没有 删除 则 进行 删除 操作 
if( kobj —>state_in_sysfs) | 





pr_debug("kobject:' 968 (%p): auto cleanup kobject_del\n" , 
kobject_name(kobj) , kobj) ; 
kobject. del( kobj) ; 


进行 实例 实体 的 释放 工作 
if(t && t-> release) | 
pr_debug( "kobject:'" 968 (%p): calling ktype release\n" , 
kobject_name(kobj) , kobj) ; 
t —>release(kobj) ; 


/ * free name if we allocated it * / 
/释放 字符 申 资 源 


if( name) | 





pr debug("kobject;' 968 ; free name\n" , name) ; 


kfree( name) ; 


| 





这 样 就 实现 了 生命 周期 的 管理 功能 。 
kobject 的 另 一 个 功能 就 是 完成 sys 文件 系统 的 组 织 功能 ， 通 过 parent、kset 、sd 等 链接 
完成 该 功能 。 相 应 的 组 织 关 系 如 图 5-13 所 示 。 
关于 设备 模型 的 初始 化 ， 相关 工作 并 不 需要 太守 执行 只 要 在 具体 的 设备 初始 化 之 前 执行 
即 可 ,图 5-14 展示 了 内 核 设备 模型 在 整个 系统 的 初始 化 的 位 置 及 流程 ， 这 对 理解 设备 模型 
有 着 实际 的 意义 。 
JARI 5-14 可 见 ， 具 体 的 设备 模型 的 初始 化 流程 在 系统 已 经 基本 初始 化 完毕 后 执行 ， 这 
时 候 sys 文件 系统 作为 一 种 特殊 的 文件 系统 已 经 注册 并 初始 化 ， 具 体 的 设备 初始 化 会 在 do_ 
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initcalls 以 函数 表 的 形式 进行 ， 在 这 之 前 就 是 设备 模型 初始 化 的 好 时 机 ， 由 driver init 来 完 
成 ， 其 内 部 会 进行 总 线 管理 初始 化 ， 功 能 设备 管理 初始 化 ，platform 总 线 初始 化 等 。 其 中 会 
向 sys 文件 系统 中 添加 对 应 的 节点 。sys 文件 系统 中 设备 相关 的 初始 化 则 在 devices. init 中 执 
行 ， 细 节 如 图 5$-15 所 示 。 

一 > kset child list 

cami pum > kobject -> kparent 


------- > kobject -> kset 


kobject 











图 5-13 sys 文件 系统 数据 结构 组 织 关 系 
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5-14 设备 模型 初始 化 
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kset create and add() e 
devices init() kobject create and _add();, 
kobject_create_and _add0、 


kobject_create_and -addo \ 


devices | 


Isys/devices 


———————————--- 






dev uevent filter 
kset 








dev uevent name 


TARRA ; dev_uevent 


d 


devices kset 


sysfs dev block kobj 


BI 5-15 sys 文件 系统 设备 相关 初始 化 


从 图 5-15 主要 的 几 个 与 device 相关 的 目录 在 此 创建 ， 为 后 续 实 体 在 相应 目录 下 
创建 做 准备 。 这 样 就 对 设备 模型 的 设计 框架 有 了 基本 的 认识 。 








5.2.2 总 线 (bus) 


总 线 是 进行 设备 连接 的 实体 ， 连 接 的 两 端 是 处 理 器 与 设备 ， 处 理 器 需要 通过 总 线 来 访问 
和 操作 设备 。 在 设备 模型 中 总 线 也 承担 了 连接 的 功能 ， 由 于 是 在 处 理 器 上 执行 ， 所 以 这 里 连 
接 的 是 设备 和 对 设备 进行 操作 的 实体 驱动 ， 其 主要 功能 就 是 将 设备 和 正确 的 驱动 绑 定 ， 从 而 
使 用 设备 ， 另 外 针对 设备 的 电源 管理 提供 统一 的 操作 接口 。 针 对 这 些 需 求 ， 设 备 模型 抽象 出 











总 线 的 实体 bus_type， 具 体 的 内 容 和 分 析 如 下 : 


struct bus_type | 
// 总 线 名 称 
const char * name; 
// 总 线 中 针对 总 线 , 设 备 和 驱动 统一 的 属 


struct bus_attribute * bus_attrs; 





H 
RE 





struct device, attribute * dev, attrs ; 


struct driver attribute * drv_attrs; 





// 总 线 特 殊 操 作用 于 检查 相应 的 设备 和 驱动 是 否 匹 配 


int( * match) (struct device * dev, struct device driver * drv); 


// kB VUE C US TIER REAR AS ACIS RAe 


E PR C 





int( * uevent) ( struct device * dev, struct kobj uevent env * env); 


31] 























// 这 里 是 强制 绑 定 驱动 和 设备 的 接口 操作 ,用 于 总 线 中 为 驱动 指定 设备 时 的 操作 
int( * probe) (struct device * dev) ; 

// 设 备 从 总 线 移 除 的 接口 
int( * remove) (struct device * dev) ; 
// 总 线 关闭 设备 的 接口 


void( * shutdown) (struct device * dev) ; 











// 总 线 设 备 需 要 sleep 时 的 接口 ,这 里 属于 遗留 的 接口 一 般 都 不 设置 
int( * suspend) ( struct device * dev, pm, message t MN ; 
// 设 备 从 sleep 恢复 时 总 线 需要 进行 操作 的 接口 ,这 里 属于 遗留 接口 一 般 都 不 设置 


int( * resume) (struct device * dev) ; 


«d 





















































// 总 线 上 设备 电源 管理 相关 的 接口 ,这 里 是 包含 各 种 电源 管理 属性 的 接口 


const struct dev. pm ops * pm; 



























































// 这 里 包含 的 数据 为 总 线 管 理 的 设备 和 驱动 与 sys 文件 系统 相关 的 实体 
struct bus type private * p; 


E 
其 中 总 线 管 理 的 主要 信息 都 在 bus_type_private ， 具 体 信 息 如 下 : 


struct bus_type_private | 
struct kset subsys; 
struct kset * drivers_kset; 
struct kset * devices_kset; 
struct klist klist_devices; 
struct klist klist_drivers ; 
struct blocking notifier head bus notifier; 
unsigned int drivers autoprobe :1 ; 
struct bus type * bus; 


l; 


相应 的 总 线 注 册 接 口 是 bus_register， 其 中 主要 创建 sys 相关 节点 并 填充 bus_type_private 
中 管理 的 内 容 。 
下 面 以 platform bus 为 例 进行 详细 分 析 : 


struct bus_type platform_bus_type = | 
. name =" platform" , 


. dev. attrs = platform, dev. attrs, 


. match = platform, match, 
. uevent = platform, uevent, 
.pm = &platform dev. pm. ops, 
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其 中 主要 的 是 match 接口 ， 用 于 匹配 设备 和 驱动 ， 细 节 如 下 : 


static int platform_match( struct device * dev, struct device_driver * drv) 
| 

// 转 换 为 总 线 实际 特定 的 设备 和 驱动 

struct platform device * pdev =to_platform_device( dev) ; 


struct platform driver * pdrv = to. platform. driver( drv) ; 


/ * Attempt an OF style match first * / 
// 首 先 按照 device tree 的 方式 检查 是 否 匹 配 


if( of_driver_match_device( dev, drv) ) 





return 1; 


/ * Then try to match against the id table * / 
// 如 果 驱 动 对 管理 的 设备 号 有 限制 需要 检查 
if( pdrv -> id. table) 
return platform, match, id( pdrv —» id. table, pdev) ! = NULL; 








/ * fall — back to driver name match * / 
// 通 常 采用 检查 名 字 的 方式 进行 匹配 ,只 要 设备 和 驱动 名 字 相 同 就 是 匹配 了 . 


return( stremp( pdev -> name, drv -> name) ==0) ; 


| 


这 里 检查 到 匹配 后 会 由 相应 的 驱动 通过 probe 接口 来 调查 设备 管理 需要 的 资源 ， 并 对 相 
应 的 资源 进行 申请 绑 定 以 及 初始 化 操作 ， 从 而 最 终 完 成 设备 和 驱动 的 绑 定 。 
驱动 模型 中 总 线 相关 的 初始 化 细节 如 图 5-16 所 示 。 








filter 





€ Isysibus 














platform_pm_prepare() 
$ een em eet 








Al5-16 设备 模型 总 线 相关 初始 化 
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从 图 5-16 可 见 ， 整 体 的 总 线 初 始 化 只 是 创建 sys 文件 系统 中 bus W, M platform 总 线 
初始 化 会 创建 总 线 节 点 及 管理 设备 和 了 驱动 的 节点 ， 这 样 方便 了 管理 ， 也 为 后 续 加 入 的 设备 和 








了 驱动 提供 良好 直观 的 接口 。 
5.2.3 驱动 (driver) 

















设备 模型 中 驱动 的 主要 功能 是 和 设备 绑 定 后 为 使 用 设备 提 伐 























t 相 关 的 操作 服务 。 既 然 是 服 


务 就 可 以 为 多 个 设备 提供 ， 只 要 与 设备 匹配 ， 服 务 功 能 就 能 正确 地 完成 。 设 备 模型 中 管理 驱 
动 的 数据 结构 是 device_driver， 其 中 包含 驱动 提供 的 通用 服务 的 接口 ， 下 面 对 它 进行 分 析 : 











struct device, driver | 











// 驱 动 名 字 

const char * name; 

// 所 属 总 线 

struct bus_type * bus; 

struct module * Owner; 

const char * mod_name; /* used for built -in modules */ 














/人 /取消 绑 定 功能 的 属性 值 








bool suppress_bind_attrs ; / * disables bind/unbind via sysfs * / 


#if defined( CONFIG_OF) 

//open firmware device tree 相关 

const struct of. device. id * of match, table; 
#endif 


/匹配 到 设备 后 ,探测 设备 资源 并 申请 初始 化 的 接口 
int( * probe) (struct device * dev) ; 

// 设 备 remove 时 的 接口 

int( * remove) (struct device * dev) ; 

// 设 备 shutdown 时 的 接口 

void( * shutdown) (struct device * dev) ; 

//5 bus 相同 遗留 接口 

int( * suspend) (struct device * dev, pm_message_t state) ; 
int( * resume) (struct device * dev); 


const struct attribute group ** groups; 


























// 电 源 管理 接口 











const struct dev. pm ops * pm; 
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// T£ sys 文件 系统 中 管理 的 资源 


struct driver_private * p; 





ie 


来 看 看 sys 文件 系统 中 驱动 之 下 主要 管理 哪些 实体 : 


struct driver_private | 
struct kobject kobj ; 
struct klist klist, devices ; 
struct klist node knode. bus; 
struct module kobject * mkobj ; 
struct device driver * driver; 


E 


从 driver. private 可 见 ， 其 中 主要 的 信息 是 运行 中 使 用 该 驱动 的 设备 列表 。 

device, driver 还 是 抽象 层面 的 实体 ， 而 到 具体 的 总 线 时 ， 相 应 的 驱动 要 有 与 总 线 相关 的 
驱动 实体 ， 因 为 只 有 具体 总 线 的 驱动 才 会 了 解 相 应 总 线 的 设备 ， 相 应 的 服务 接口 也 要 与 具体 
的 总 线 设备 相关 。 从 这 个 层面 上 讲 设 备 模型 中 的 驱动 与 总 线 关 系 更 紧密 。 

以 platform 驱动 实体 为 例 进行 分 析 : 




















struct platform_driver | 
int( * probe) (struct platform, device * ) ; 
int( * remove) (struct platform device * ) ; 
void( * shutdown) (struct platform device * ) ; 
int( * suspend) (struct platform. device * , pm. message t state) ; 
int( * resume) (struct platform device * ) ; 
struct device driver driver; 


const struct platform. device id * id table; 


E 


其 中 定义 了 总 线 设备 相关 的 服务 接口 : 





int platform_driver_register( struct platform_driver * drv) 
| 
drv -> driver. bus = &platform_bus_type; 
if( drv -> probe) 
drv —> driver. probe = platform, drv. probe; 
if( drv - » remove) 
drv —> driver. remove = platform. drv. remove ; 
if( drv —> shutdown) 


drv —> driver. shutdown = platform. drv. shutdown ; 
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return driver_register( &drv —> driver) ; 


| 


从 platform 驱动 注册 接口 可 以 看 出 ， 抽 象 层 的 服务 接口 都 被 换 为 实例 化 的 接口 ， 这 样 内 
HAY driver 可 以 通过 设备 模型 核心 提供 的 标准 操作 进行 管理 ， 也 可 以 通过 这 些 实例 化 接口 进 
行 转换 。 

系统 中 设备 与 驱动 绑 定 的 流程 如 图 5-17 所 示 。 















ploba platform_drv_probe 
Sa TUE RID remove — vl Eli LONG LACT 
> € Ss shutdown” ESTE M S TTL lena kzalloc drv space 
- oA AP" init kset & kobj 
X i 


driver_register(drv) 











bus_autoprobe? 





bus_add_driver 







driver_find(drv) 









platform_match pm_runtime_barrier «rest of stuff» 
a really_probe 


pm_runtime_put_sync 








bus_for_each_dev 









. driver attach 






driver_probe_device 





driver_sysfs_add() 


xxx_probe() 
driver_bound() 


图 5-17 驱动 与 设备 绑 定 的 流程 











从 图 5-17 可 见 ， 具体 总 线 驱 动 在 注册 的 时 候 就 会 根据 总 线 是 否 自动 probe 设备 (通常 
自动 有 效 ) 来 进行 设备 的 绑 定 ， 为 了 实现 该 功能 设备 模型 核心 提供 了 很 多 接口 方便 设备 和 
驱动 的 绑 定 ， 相 应 的 功能 也 是 十 分 完善 的 。 其 中 添加 driver 的 接口 就 是 driver_register， 来 看 
看 具体 的 内 容 : 











int driver_register( struct device, driver * drv) 
int ret ; 
struct device, driver * other; 


BUG ON(! drv -> bus -» p) ; 





// 首 先 检 查 接口 是 否 齐 全 ,相应 的 接口 必须 有 
if( ( drv -> bus -> probe && drv -> probe) || 
(drv -> bus —> remove && drv — > remove) || 











(drv -> bus - » shutdown && drv -> shutdown) ) 
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printk( KERN, WARNING " Driver 968 needs updating — please use " 


" bus, type methods Wn" , drv -> name) ; 


// 检 查 driver 是 否 已 经 注册 
other = driver_find( drv -> name, drv —> bus) ; 
if(other) | 
printk( KERN, ERR " Error; Driver’ %s is already registered, " 
"aborting... Wn" , drv -> name) ; 
return — EBUSY; 











// 通 过 总 线 添加 ,这 里 之 前 要 说 明 总 线 类 型 
ret = bus, add, driver( drv) ; 
if( ret) 

return ret; 
// Xf driver 设置 接口 即 属性 
ret = driver_add_groups(drv, drv —> groups) ; 
if( ret) 


bus, remove. driver( drv) ; 











return ret ; 


| 


从 代码 中 可 见 ， 设 备 模 型 管理 的 device_driver 必须 与 bus 关联 ， 因 为 只 有 bus 才能 帮 其 
找到 所 管理 的 设备 ， 而 具体 的 总 线 都 会 如 platform 总 线 一 样 封 装 出 注册 driver 的 接口 函数 ， 
并 将 device, driver 的 bus 属性 填 人 人， 为 上 层 提供 统一 的 接口 ， 也 避免 跨 层 设置 。 后 续 的 操作 
如 图 5-17 所 示 ， 根 据 bus 的 自动 probe 属性 来 进行 具体 总 线 的 设备 与 驱动 的 绑 定 。 


5.2.4 设备 (devices) 


对 设备 模型 中 的 设备 ， 考 虚 的 重点 是 如 何 进行 抽象 。 任 何 设备 要 使 用 都 是 需要 资源 的 ， 
无 论 是 自身 的 资源 还 是 系统 的 资源 ， 所 以 应 从 其 拥有 的 资源 考虑 进行 抽象 。 
具体 分 析 设 备 模 型 中 的 设备 管理 ， 首 先 要 分 析 device 结构 。 


















































struct device | 
// 表 示 设 备 的 层次 关系 


























struct device * parent; 
// 设 备 模型 核心 使 用 ,其 中 有 设备 实例 化 私有 数据 
struct device_private * p; 


/人 /生命 周期 管理 实体 
struct kobject kobj ; 








了 77 
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const char * init_name; / * initial name of the device * / 
// 功 能 类 设备 和 总 线 类 设备 中 都 可 能 有 不 同 的 类 型 ,这 里 是 相应 的 类 型 实例 化 


struct device_type * type; 





struct mutex mutex ; / * mutex to synchronize calls to its driver. * / 


// 总 线 类 设备 所 在 总 线 


struct bus type — ** bus; / * type of bus device is on * / 

// XE BR CE] 

struct device driver * driver; / * which driver has allocated this device * / 

void * platform, data; /* Platform specific data, device core doesn’ t touch 
it */ 











// 设 备 电 源 管理 需要 的 信息 


struct dev_pm_infopower; 




















// 设 备 使 用 DMA 时 访问 资源 的 限制 说 明 

u64 * dma_mask; / * dma mask(if dma’ able device) */ 

u64 coherent, dma mask; / * Like dma mask, but for alloc. coherent mappings as 
not all hardware supports 64 bit addresses for con- 
sistent 


allocations such descriptors. * / 





// 以 下 是 DMA 参数 及 资源 属性 说 明 


struct device_dma_parameters * dma_parms; 





struct list_headdma_pools;/ * dma pools(if dma’ ble) */ 


struct dma_coherent_mem * dma_mem; / * internal for coherent mem override * / 
/ * arch specific additions * / 
struct dev_archdataarchdata ; 
#ifdef CONFIG_OF 
struct device node * of node; 


#endif 
dev_t devt; / * dev t, creates the sysfs "dev" */ 
// device resource 的 管理 实体 
spinlock t devres, lock ; 


struct list head | devres head; 


struct klist node knode, class ; 


/功能 类 设备 使 用 ,关联 到 具体 的 类 型 





struct class * class; 

const struct attribute group ** groups;/ * optional groups * / 
/实例 化 释放 的 接口 

void( * release) (struct device * dev) ; 


l; 











从 device 可 见 ， 重 点 是 管理 的 资源 ， 当 然 也 包含 针对 sys 文件 系统 关联 的 属性 。 而 设备 
的 层次 关系 在 实际 的 情况 下 通常 是 从 逻辑 层 的 功能 设备 逐渐 到 物理 层 的 总 线 设 备 ， 最 终 到 
platform bus 中 对 应 的 device ， 这 样 系统 就 建立 了 完整 的 设备 层次 关系 。 

还 是 以 platform 总 线 的 设备 进行 实例 化 分 析 : 














struct platform_device | 


const char * name; 

int id; 

struct device dev; 

u32 num resources ; 


struct resource * resource; 
const struct platform. device id * id entry; 


/ * arch specific additions * / 


struct pdev_archdata archdata ; 


l; 


这 里 可 以 理解 为 其 记录 总 线 相 关 的 特殊 资源 ， 但 实际 又 有 platform 总 线 的 特殊 性 ，re- 
sources 实际 是 各 种 资源 的 抽象 ， 其 中 包含 中 断 、I0 空间 等 。 其 资源 具体 的 类 型 在 ioport. h 
中 定义 ， 具 体 如 下 : 





#define IORESOURCE_IO 0x 00000100 
#define IORESOURCE_MEM 0x 00000200 
#define IORESOURCE_IRQ 0x 00000400 
#define IORESOURCE_DMA 0x 00000800 
#define IORESOURCE_BUS Ox 00001000 


可 见 platform 设备 管理 的 资源 就 是 物理 设备 的 各 种 资源 ， 这 和 实际 也 是 一 致 的 。 
整体 来 说 ， 设 备 模型 中 的 设备 就 是 管理 资源 以 供 驱 动 访问 和 操作 ， 资 源 管理 是 设备 管理 
的 一 个 核心 。 
当然 设备 管理 还 需要 能 为 用 户 创建 合适 的 操作 接口 文件 ， 不 能 因为 创建 时 间 的 差异 而 产 
生 不 同 的 文件 名 ， 这 就 需要 和 用 户 层 的 管理 程序 结合 ， 相 应 的 框架 和 流程 如 图 5-18 所 示 。 
从 图 5-18 可 见 ， 内 核 设备 模型 和 udev 紧密 结合 ， 按 从 1 ~6 的 顺序 执行 最 终 对 固定 的 设备 产 
生 固定 的 操作 接口 文件 ， 从 而 保证 了 应 用 的 一 致 视角 。 设 备 模型 通知 udev 的 方式 如 图 $-19 所 示 。 
通过 uevent 通知 到 应 用 层 ， 就 完成 设备 管理 创建 设备 文件 到 应 用 层 的 操作 。 这 样 设备 
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External 












{1} event 
fj; new device Core Driver 
/sbin/hotplug 
{5}load 
hotplug 
Kernel {6} message 
Users race GAG Rec ale. ee en 
: Idevittyso : 





: Idev/sda 


图 5-18 设备 模型 设备 文件 创建 流程 及 框架 



















kobject_uevent(kobj,action) 







kobject uevent env(kobj,action) 


call usermodehelper setup(::-) 
call usermodehelper setfns(:--) 
call_usermodehelper_exec(-:-) 


图 5-19 设备 模型 通知 应 用 层 流 程 






call_usermodehelper(env) 






































管理 的 功能 就 是 完整 的 了 。 
关于 设备 名 ， 设 备 模 型 提供 产生 文件 名 的 接口 device_get_devnode， 并 通过 uevent 属性 
文件 提供 给 用 户 层 ，device_get_devnode 的 细节 如 下 : 














const char * device, get _devnode( struct device * dev, 


mode t * mode, const char ** tmp) 
char * s; 
* tmp = NULL; 


/ * the device type may provide a specific name */ 


/根据 设备 类 型 加 入 特殊 的 设备 信息 ,通常 用 于 总 线 表示 不 同类 型 设备 
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if( dev -> type && dev —> type -> devnode ) 
* tmp = dev —> type -> devnode( dev, mode) ; 
if( * tmp) 


return. * tmp; 


/ * the class may provide a specific name ** / 
// 加 入 功能 类 信息 ,通常 用 于 具体 功能 的 设备 放 入 同一 个 目录 


if( dev -» class && dev -> class -> devnode) 















































* tmp = dev —> class -> devnode( dev, mode) ; 
if( * tmp) 


return. * tmp; 


/ * return name without allocation, tmp == NULL */ 
if( strehr( dev. name( dev) ,' !' ) == NULL) 


return dev. name( dev) ; 


/* replace !' in the name with / */ 
* tmp = kstrdup( dev. name( dev) , GFP. KERNEL) ; 
if(! *tmp) 


return NULL; 
while( (s = strehr( * tmp,’ !' ))) 
s[O]=/; 


return * tmp; 





设备 模型 通过 device add 接口 来 为 以 上 功能 提供 统一 的 服务 ， 具 体 细节 如 下 . 








int device, add( struct device * dev) 

| 
struct device * parent = NULL; 
struct kobject * kobj; 
struct class interface * class_intf; 
int error = — EINVAL; 


// 避 免 device 被 释放 
dev = get_device( dev) ; 
if(! dev) 


goto done; 


if(! dev-» p) | 
error = device, private init( dev) ; 


if( error) 
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goto done; 


// 建 立 设备 之 间 的 层次 关系 


parent = get_device( dev —> parent) ; 





kobj = get_device_parent(dev, parent) ; 
if( kobj ) 
dev -> kobj. parent = kobj; 


/ * use parent numa_node * / 
if( parent) 


set, dev node(dev, dev_to_node( parent) ) ; 


/ * first, register with generic layer. */ 

/ * we require the name to be set before, and pass NULL */ 
error = kobject, add( &dev -> kobj, dev -> kobj. parent, NULL) ; 
if( error) 


goto Error; 


/ * notify platform of device entry * / 
// S H FERIERE , FHTo Fr VIC CS RPE ,通常 为 空 
if( platform, notify ) 

platform, notify ( dev) ; 























zu 





// 以 下 创建 与 应 用 层 设 备 文件 创建 逻辑 ( 如 udev) 相关 的 接口 ， 
// 创 建设 备 文件 需要 的 设备 信息 


error = device, create, file( dev, &uevent_ attr) ; 














if( error) 


goto attrError; 


if( MAJOR( dev -» devt) ) | 
error = device, create, file( dev, &devt_attr) ; 
if( error) 


goto ueventattrError ; 





// 设 备 号 相关 信息 


error = device_create_sys_dev_entry( dev) ; 





if( error) 


goto devtattrError ; 


devtmpfs_create_node( dev) ; 





于 读 取 


























// 这 里 检查 设备 是 否 属于 具体 功能 类 。 如 果 是 , 则 加 入 相应 class 中 


error = device_add_class_symlinks( dev) ; 











if( error) 
goto SymlinkError; 
error = device_add_attrs( dev) ; 
if( error) 
goto AttrsError ; 
// 这 里 检查 设备 是 否 属于 具体 总 线 。 如 果 是 , 则 加 入 相应 bus 中 


error = bus_add_device( dev) ; 






































if( error) 

goto BusError ; 
// 增 加 设备 电源 管理 相关 的 
error = dpm_sysfs_add( dev) ; 





me 
zi 


u 


属性 























if( error) 

goto DPMError; 
// 将 设备 加 入 到 系统 的 pm 管理 系统 中 ,主要 是 设备 功 耗 管理 列表 
device_pm_add(dev) ; 





/ * Notify clients of device addition. This call must come 
* after dpm, sysfs add( ) and before kobject_uevent( ). 
*/ 

// 如 果 是 总 线 设备 , 则 通知 总 线 有 设备 加 入 ,关心 此 

if( dev —> bus) 

blocking_notifier_call_chain( &dev -> bus -> p -> bus, notifier, 
BUS, NOTIFY. ADD. DEVICE, dev) ; 








Ilin 














事件 的 模块 可 以 是 非 总 线 模块 。 














// 发 布 新 设备 的 事件 ,以 便 udev 进行 后 续 处 理 
kobject_uevent( &dev -> kobj, KOBJ_ADD) ; 
// 如 果 设 备 是 总 线 类 型 设备 ,这 里 会 根据 总 线 是 否 自动 probe RIETI pg 


bus_probe_device( dev) ; 





a 











if( parent) 
klist_add_tail( &dev -> p — > knode_parent , 
&parent —» p —> klist_children) ; 


// 功 能 类 型 设备 进行 的 操作 
if( dev -> class) | 
mutex_lock( &dev -> class -> p -> mutex) ; 
/ * tie the class to the device */ 
// 将 其 加 入 设备 列表 
klist_add_tail( &dev -> knode_class, 
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&dev -> class -> p -> class. devices) ; 


/ * notify any interfaces that the device is here * / 
// 通 知 注册 的 interface 有 设备 加 入 ,可 以 做 一 些 特殊 的 操作 . 
// 通 党 类 型 并 没有 注册 interface 


list, for each, entry( class intf, 





























&dev —> class -> p —> class. interfaces, node) 
if( class, intf -> add. dev) 
class intf -> add, dev(dev, class intf) ; 
mutex, unlock ( &dev -> class -> p -> mutex) ; 
} 
done: 
put, device( dev) ; 


return error; 


| 


从 代码 细节 可 见 ， 设 备 并 不 完全 与 总 线 绑 定 ， 还 有 上 层 功 能 抽象 的 功能 类 ， 这 和 之 前 的 
设备 分 类 是 吻合 的 。 具 体 的 设备 在 进行 add 操作 之 前 要 将 其 bus 或 者 class 的 属性 进行 正确 
地 设置 。 设 备 模型 提供 了 良好 的 框架 ， 具 体 的 实例 化 就 交 由 具体 的 模块 实现 。 


5.2.5 功能 类 (class) 


前 面 已 经 介绍 了 功能 类 实际 是 站 在 用 户 的 角度 的 高 级 别 抽象 ， 用 户 更 关心 功能 而 不 是 物 
理 的 连接 ， 相 应 的 设备 模型 中 也 为 其 提供 管理 实体 。class 结构 是 主要 的 管理 实体 ， 其 内 容 
如 下 : 
































struct class | 


// 类 名 。 
const char * name; 
struct module * owner; 


// 同 一 类 功能 设备 的 统一 属性 


struct class attribute — * class_attrs; 





struct device, attribute * dev, attrs ; 

// 这 里 是 上 层 抽象 的 类 型 实体 ,实际 中 是 sys 系统 的 字符 型 设备 或 者 块 类 型 设备 
// 内 核 通 过 该 属性 将 设备 加 入 到 /sys/dev 合适 的 设备 下 

struct kobject * dev_kobj; 















































// 同 一 类 功能 设备 的 操作 接口 
int( * dev_uevent) (struct device * dev, struct kobj uevent env * env); 


char * ( * devnode) (struct device * dev, mode t * mode) ; 
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void( * class, release) (struct class * class) ; 


void( * dev. release) ( struct device * dev) ; 


int( * suspend) (struct device * dev, pm, message t state) ; 


int( * resume) (struct device * dev); 


const struct kobj ns type operations * ns type; 


const void * ( * namespace) (struct device * dev) ; 








// 电 源 管理 接口 


const struct dev. pm ops * pm; 




















// 所 管理 的 信息 


struct class private * p; 








E 
看 看 class 所 管理 的 内 容 : 


struct class_private | 
struct kset class_subsys; 
struct klist class_devices; 
struct list_head class_interfaces ; 
struct kset class_dirs; 
struct mutex class mutex ; 


struct class * class; 


i 





从 class 管理 的 信息 来 看 只 有 设备 ， 这 是 为 什么 ?为 什么 没有 驱动 ? 仔细 考虑 一 下 ， 这 
些 都 是 从 用 户 的 角度 考虑 的 类 型 ， 用 户 对 设备 的 操作 接口 是 文件 ， 所 以 相应 的 驱动 是 通过 文 
件 操作 接口 实现 相关 功能 ， 这 里 不 对 文件 进行 管理 ， 所 以 没有 驱动 实体 。 

另 系统 提供 了 注册 class 的 接口 ， 具 体 如 下 : 























extern int __must_check __class_register(struct class * class, struct lock_class_key * key) ; 











功能 型 驱动 框架 最 终 都 会 调用 该 接口 注册 功能 类 。 
5.2.6 设备 资源 管理 (device resource) 


对 设备 所 需 资源 进行 管理 时 ， 驱 动 经 常 要 人 处理 各 种 资源 分 配 和 释放 时 的 异常 情况 ， 相 关 
的 代码 有 随意 性 、 稳 定性 的 问题 ， 内 核 的 开发 者 针对 这 种 情况 开发 了 统一 的 接口 方便 驱动 的 
开发 者 进行 资源 的 申请 和 释放 ， 这 样 可 以 简化 驱动 的 开发 减少 元 余 代码 ， 使 开发 者 更 专注 于 
核心 的 内 容 而 不 是 资源 的 分 配 和 释放 。 熟 悉 这 些 接口 对 于 驱动 的 开发 大 有 好 处 ， 下 面 列 出 主 
要 的 资源 和 接口 : 
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内 存 


devm, kzalloc( ) 
devm, kfree( ) 


IO 空间 


devm, request, region( ) 
devm, request, mem region( ) 
devm, release region( ) 


devm, release mem  region( ) 


devm, request, irq( ) 
devm, free, irq( ) 

DMA 资源 
dmam, alloc, coherent( ) 
dmam, free, coherent( ) 
dmam_alloc_noncoherent( ) 
dmam, free. noncoherent( ) 
dmam, declare, coherent, memory ( ) 
dmam, pool. create( ) 


dmam, pool. destroy ( ) 
10 映射 


devm, ioremap( ) 
devm_ioremap_nocache( ) 


devm, iounmap( ) 
时 钟 


devm, elk, get( ) 
devm, elk, put( ) 


以 上 基本 涵盖 了 设备 驱动 开发 使 用 的 主要 资源 ， 其 实现 是 与 设备 模型 的 device 相 结合 ， 
这 样 资源 和 设备 就 进行 强 关联 ， 从 而 可 以 简化 管理 。 











5.3 字符 设备 (char device) 


5.3.1 字符 设备 的 特点 和 需求 


字符 设备 是 Linux 内 核 管理 设备 中 的 一 大 类 设备 ， 在 设备 模型 介绍 中 可 以 看 到 系统 初始 
化 的 时 候 在 sys 文件 系统 下 创建 了 两 大 类 设备 ， 分 别 是 字符 设备 和 块 设备 ， 这 样 做 是 系统 管 
理 的 需要 ， 在 设备 管理 中 同样 要 进行 分 层 化 的 管理 ， 只 有 这 样 才能 简化 VES 层 的 处 理 ， 从 
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层 分 类 。 在 进行 设备 分 类 时 是 要 以 数据 为 核心 ,不 同类 型 的 设备 对 数据 的 组 织 方式 以 及 数据 
操作 特点 是 不 同 的 ， 在 顶层 进行 区 分 就 要 在 高 层 抽 象 考虑 。 字 符 设备 处 理 的 数据 属于 流 式 
(stream) ， 特 点 是 数据 需要 进行 顺序 处 理 ， 不 能 进行 回 读 。 流 式 数据 本 身 的 组 织 和 结构 化 特 
点 是 偏向 应 用 ， 并 不 由 内 核 其 他 模块 进行 再 封装 ， 在 层次 上 就 可 以 直接 面向 应 用 层 。 

应 用 层 直 接 使 用 的 用 户 界面 (UI) 相关 的 设备 都 具有 以 上 的 特点 ， 所 以 都 归于 字符 设 
备 ， 这 也 是 设备 层次 管理 的 需要 ， 和 否则 由 于 增加 了 不 同类 型 的 文件 ，VFS 和 具体 文件 系统 都 
需要 增加 复杂 度 。 字 符 设备 框架 需要 能 够 区 分 不 同 的 设备 类 型 并 管理 相关 设备 及 其 操作 ， 男 
外 需要 能 够 为 VES 层 提 供 设备 重 载 的 功能 ， 将 正确 的 设备 操作 提供 给 应 用 层 。 由 于 是 上 层 
抽象 的 设备 ,需要 支持 各 种 类 型 的 设备 ， 在 上 层 抽 象 进行 生命 周期 的 管理 会 便于 底层 框架 的 
开发 ， 男 外 需要 文 持 hotplug (动态 加 载 移 除 ) 的 设备 ， 这 就 要 求 字 符 设 备 框架 层 支 持 相应 
的 用 户 设备 文件 的 动态 有 效 性 。 


5.3.2. 字符 设备 的 核心 数据 结构 及 操作 


下 面 介 绍 字符 设备 的 框架 ， 字 符 设备 的 核心 数据 结构 是 cdev, 具体 内容 如 下 : 























































































































struct cdev | 
/与 设备 模型 关联 ,负责 相关 生命 周期 管理 
struct kobject kobj ; 














ne 











struct module * owner; 

// 设 备 特定 的 文件 操作 接口 

const struct file_operations * ops; 

// Ej VFS 中 inode 关联 负责 文件 动态 有 效 性 
struct list_head list; 

// 设 备 号 


dev_t dev; 





unsigned int count; 


E 


从 相应 的 属性 中 可 见 ， 以 上 的 需求 都 可 以 通过 该 结构 进行 管理 。 

1. 生命 周期 管理 

首先 ， 在 字符 设备 框架 中 ， 生 命 周期 管理 是 通过 kobj 进行 的 ， 相 应 的 管理 已 经 通过 字 
符 设备 框架 进行 封装 ， 并 通过 对 外 的 接口 统一 提供 相关 功能 。 包 含 生命 周期 管理 的 字符 设备 
框架 对 外 接口 如 下 : 





























void cdev_init( struct cdev * , const struct file operations * ) ; 
struct cdev * cdev_alloc( void) ; 
void cdev_put( struct cdev * p); 


void cdev_del( struct cdev * ) ; 


cdev. get 设计 成 内 部 使 用 接口 ， 在 文件 打开 时 通过 chrdev open 进行 调用 ， 这 样 可 以 保 
证 引用 计数 的 增加 ， 从 而 保证 不 被 释放 。 
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下 面 来 看 看 在 cdev 生命 周期 结束 时 的 操作 : 


static struct kobj_type ktype_cdev_default = | 
. release = cdev_default_release , 


E 


static struct kobj. type ktype, cdev. dynamic = | 
. release = cdev. dynamic, release, 


l; 


static void cdev_default_release( struct kobject * kobj) 


| 


struct cdev * p =container_of(kobj, struct cdev, kobj) ; 


cdev_purge(p) ; 


static void edev_dynamic_release( struct kobject * kobj) 


| 


struct cdev * p =container_of(kobj, struct cdev, kobj) ; 
cdev_purge(p) ; 
kfree( p) ; 


| 


为 什么 会 有 两 个 很 接近 的 操作 呢 ? 这 是 由 于 对 cdev 的 创建 分 别 有 静 态 地 创建 cdev_init 和 动 
态 地 创建 cdev_alloc 两 种 ， 对 应 用 生命 周期 结束 同样 有 两 种 、 项 态 使 用 cdev_default_release 、 动 态 
使 用 cdev_dynamic_release。 动 态 比 静态 增加 了 释放 内 存 的 操作 。 但 是 cdev_purge 的 工作 是 什么 
呢 ? 在 需求 讨论 的 时 候 提 到 了 字符 设备 是 对 用 户 开 放 使 用 的 ， 这 里 设备 的 生命 周期 结束 时 一 般 是 
驱动 释放 操作 ， 相 应 的 VFS 中 代表 实际 文件 inode 的 属性 就 应 该 调整 ， 该 函数 就 是 将 inode 与 
cdev 的 关联 关闭 ， 后 续 的 打开 设备 文件 操作 会 重新 加 载 设备 驱动 ， 这 样 才能 保证 系统 的 正确 性 。 

2. 设备 分 类 管理 

对 设备 的 分 类 和 具体 设备 的 管理 ， 系 统 通 过 设备 号 来 进行 ,设备 号 是 具体 设备 的 类 型 和 
实体 的 综合 ， 与 设备 一 一 对 应 ， 由 于 通过 设备 号 进行 设备 管理 是 通用 的 方式 ， 同 样 适合 于 块 
设备 ， 而 不 同 的 设备 对 设备 号 的 管理 方式 会 有 差别 ， 所 以 各 自 进行 单独 的 设备 号 管理 。 

对 抽象 设备 实体 如 cdev 的 管理 ， 从 设计 的 角度 和 设备 号 分 离 灵 活性 更 高 考虑 ， 将 二 者 
进行 分 离 管理 。 

下 面 详细 分 析 设 备 号 管理 ， 对 字符 设备 的 设备 号 进行 管理 的 核心 实体 是 char. device 
struct， 详 细 内 容 如 下 : 


































































































static struct char_device_struct | 
struct char_device_struct * next; 
unsigned int major; 
unsigned int baseminor; 


int minorct; 
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char name| 64 ] ; 
struct cdev * cdev; /* will die */ 


| = chrdevs| CHRDEV, MAJOR, HASH, SIZE] ; 

















字符 设备 分 类 比较 特殊 ， 并 不 是 只 通过 主 设备 号 来 进行 分 类 的 ， 允 许 将 主 设备 管理 的 子 
设备 号 分 开 表示 不 同类 型 的 设备 ， 作 为 主 类 型 下 面 的 子 类 型 ， 每 种 类 型 有 自己 的 驱动 ，char 
device, struct 就 是 用 来 进行 这 种 分 类 管理 以 及 和 驱动 绑 定 的 。 可 见 其 中 通过 major 主 设备 
，basemonor 基本 的 子 设备 号 以 及 minoret 子 设备 数目 来 表示 所 管理 的 设备 。 相 应 管理 的 底 
ZAREE register chrdev. region 中 ， 相 应 的 接口 如 下 : 




















qu 














static struct char. device struct * 
. register chrdev, region( unsigned int major, unsigned int baseminor, 


int minorct, const char * name) 

















如 果 major 设置 为 0， 则 进行 主 设备 号 的 动态 分 配 。 相 应 的 系统 也 提供 静态 申请 设备 号 
和 动态 申请 设备 号 两 个 接口 ， 分 别 如 下 : 











int register_chrdev_region( dev_t from, unsigned count, const char * name) 


int alloc_chrdev_region(dev_t * dev, unsigned baseminor, unsigned count, const char * name) 


其 中 register. chrdev, region 为 静态 申请 主 设备 号 ，alloc_chrdev_region 为 动态 分 配 主 设 
备 号 。 

3. cdev 实体 管理 

对 字符 设备 来 说 ， 由 于 其 主要 为 用 户 直 接 使 用 ， 而 没有 与 内 核 中 除 VES 外 的 其 他 模块 
关联 ， 所 以 设计 时 将 cdev 既 作为 对 上 层 VES 的 接口 也 作为 对 下 层 驱 动 框架 的 接口 ， 来 进行 
统一 管理 。 男 外 在 内 核 中 针对 字符 设备 和 块 设备 类 型 设计 了 统一 的 设备 驱动 管理 实体 的 管理 
框架 ， 主 要 的 数据 结构 如 下 : 




















struct kobj_map | 

struct probe | 
struct probe * next; 
dev_t dev; 
unsigned long range; 
struct module * owner; 
kobj_probe_t * get; 
int( * lock) (dev. t, void * ); 
void * data; 

| * probes| 255 | ; 

struct mutex * lock; 


E 





其 中 dev 为 驱动 管理 的 起 始 设备 号 ，range 为 管理 的 范围 ，data 对 字符 设备 驱动 来 说 就 
了 29 








是 指向 cdev (也 作为 设备 驱动 管理 实体 )。 
相应 的 内 核 提 供 添 加 和 查找 的 功能 ， 接 口 分 别 如 下 : 











int kobj_map(struct kobj_map * domain, dev_t dev, unsigned long range, 
struct module * module, kobj probe t * probe, 


int( * lock) (dev t, void * ), void * data) 


struct kobject * kobj_lookup( struct kobj map * domain, dev. t dev, int * index) 


具体 的 由 kobj map 负责 添加 ， 由 kobj lookup 负责 查找 。 
字符 设备 为 了 底层 设备 框架 开发 方便 将 添加 接口 封装 为 cdev_ add 以 便 调 用 ， 细 节 
WF: 











int cdev_add( struct cdev * p, dev t dev, unsigned count) 


p —> dev = dev; 
p —> count = count; 


return kobj_map(cdev_map, dev, count, NULL, exact_match, exact_lock, p); 


| 


从 代码 中 可 见 ， 其 直接 调用 kobj_map 来 实现 功能 。 

4. 字符 设备 驱动 注册 流程 

对 字符 设备 驱动 来 说 ， 由 于 其 管理 的 设备 号 和 管理 实体 cdev 是 分 开 管理 的 ， 所 以 字符 
设备 驱动 的 注册 流程 是 : 首先 进行 所 管理 的 设备 号 的 申请 (可 以 静态 申请 也 可 以 动态 申 
请 ) ; 然后 是 管理 实体 cdev 的 申请 〈 可 以 静态 初始 化 和 动态 申请 ) ; 最 后 通过 cdev_add 加 入 
进行 统一 管理 即 可 。 新 的 字符 设备 驱动 都 是 采用 这 种 方式 注册 。 

对 于 字符 设备 驱动 的 注册 ， 老 的 内 核 使 用 register chrdev 进行 ， 系 统 需 要 兼容 老 的 内 核 ， 
所 以 提供 了 接口 函数 __register_chrdev， 而 register_chrdev 就 是 简单 地 调用 __register_chrdev， 
下 面 通过 _register_chrdev 来 了 解 新 的 注册 过 程 。 















































int, register chrdev( unsigned int major, unsigned int baseminor, 
unsigned int count, const char ** name, 


const struct file operations * fops) 


struct char. device, struct. * cd; 
struct cdev * cdev; 
int err = - ENOMEM; 


/获得 管理 的 设备 号 范围 
cd = we T major, baseminor, count, name); 
if(IS ERR(cd) ) 

return PTR, ERR( ed) ; 
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// 动 态 分 配 cdev 驱动 管理 实体 
cdev = cdev_alloc() ; 
if(! cdev) 


goto out? ; 














/正确 的 设置 参数 , 主要 是 文件 操作 接口 


cdev —> owner = fops — > owner; 














cdev —> ops = fops; 


kobject_set_name( &cdev -> kobj, "96s" , name); 


// 将 驱动 管理 实体 加 入 系统 进行 管理 
err =cdev_add(cdev, MKDEV(cd -> major, baseminor) , count) ; 
if( err) 


goto out ; 








cd —» cdev = cdev; 


return major ? 0 : cd -> major; 
out : 
kobject. put( &edev -> kobj) ; 
out2 : 
kfree(__unregister_chrdev_region( cd -> major, baseminor, count) ) ; 


return err; 


static inline int register, chrdev( unsigned int major, const char * name, 


const struct file operations * fops) 





// 老 的 接口 对 于 子 设备 只 有 256 个 的 限制 . 


return __register_chrdev( major, 0, 256, name, fops) ; 








| 








驱动 注册 之 后 ， 就 等 待 应 用 程序 打开 并 使 用 相应 的 设备 了 。 使 用 设备 的 操作 都 是 由 各 种 
类 型 的 驱动 框架 提供 ， 相 应 的 会 调用 驱动 具体 的 接口 函数 。 

5. 设备 操作 的 重 载 

字符 设备 作为 上 层 的 抽象 设备 ， 要 担负 起 操作 重 载 的 工作 ， 这 部 分 工作 是 在 VES 中 完 
成 的 ， 接 下 来 看 看 具体 的 实现 : 





























uj 





// Z ij VES 中 介绍 的 获得 inode 时 加 载 的 操作 接口 ,目的 是 等 到 打开 设备 才 进 行 重 载 


const struct file_operations def_chr_fops = | 





. open = chrdev_open, 


. llseek = noop_llseek , 
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bs 


static int chrdev_open( struct inode * inode, struct file * filp) 


| 


struct cdev * p; 
struct cdev * new = NULL; 


int ret =0; 


spin, lock( &cdev_lock) ; 
// 这 里 获得 和 文件 管理 相关 的 cdev 实体 ,cdev 作为 VFS 的 接口 实体 
p = inode -»i cdev; 
//p 为 空 说 明之 前 没有 打开 过 
if(! p) | 
struct kobject * kobj ; 























int idx ; 
spin, unlock ( &edev. lock) ; 
// 根 据 设备 号 返回 cdev 中 的 kobj 
kobj = kobj_lookup( edev. map, inode -> i rdev, &idx) ; 
if( ! kobj) 
return — ENXIO; 
// 获 得 cdev 实体 
new = container of(kobj, struct cdev, kobj) ; 


spin. lock( &edev. lock) ; 





/ * Check i cdev again in case somebody beat us to it while 
we dropped the lock. */ 
// 由 于 之 前 的 操作 unlock 了 锁 ,所 以 有 可 能 其 他 模块 已 经 进行 了 设置 
// 这 里 进行 一 下 检查 
p = inode -»i cdev; 
//p 为 空 说 明 没有 设置 过 
if(! p) | 
// 将 文件 和 cdev 关联 
inode -> i_cdev = p = new; 
list_add( &inode -> i devices, &p —> list) ; 
// 获 得 cdev, 这 里 的 设置 避免 put 释放 操作 
new = NULL; 
| else if( | cdev_get(p) ) 
ret = — ENXIO; 
| else if( | cdev_get(p) ) 
ret = — ENXIO; 






































spin, unlock ( &edev_lock) ; 
// 之 前 kobj lookup 会 进行 get 操作 ,这 里 已 经 用 完 , 应 该 进行 put 操作 . 


cdev_put( new) ; 


if( ret) 


return ret; 


ret = — ENXIO; 

// 这 里 进行 文件 操作 的 重 载 ,使 用 的 是 特定 驱动 框架 的 接口 
filp -»f op = fops get(p -> ops) ; 

if( ! filp -»f op) 


goto out, cdev. put; 









































/进行 重 载 后 的 打开 操作 
if(filp ->f op -> open) | 








ret = filp ->f op -> open( inode , filp) ; 
if( ret) 


goto out, cdev. put; 


return 0; 


out, cdev. put: 
cdev_put(p) ; 


return ret; 


| 





重 载 对 用 户 来 说 是 不 可 见 的 ， 用户 并 没有 感受 到 相应 的 重 载 过 程 。 这 样 实现 也 是 满足 设 
备 层 次 管理 的 需要 。 


5.3.3 字符 设备 子 类 型 


字符 设备 分 类 可 以 在 系统 启动 后 从 proc 文件 系统 和 sys 文件 系统 中 获得 相关 信息 。 
首先 看 看 /proc/devices 下 面 的 信息 : 

















Character devices: 
mem 
/dev/ve/0 

tty 

ttyS 

/ dev/tty 

/ dev/console 
/ dev/ptmx 
ttyprintk 

lp 


vcs 


a O € tU t A RR BP PE 
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10 misc 
13 input 
14 sound 
21 sg 
29 fb 
81 videodlinux 
99 ppdev 
108 ppp 
116 alsa 
128 ptm 
136 pts 
180 usb 
189 usb device 
216 rfcomm 
226 drm 
251 hidraw 
252 bsg 
253 watchdog 
254 rte 


里 只 是 列 出 了 主 设备 号 ， o et rs 的 。 更 细 
xs \ 可 以 从 /sys/dev/char 下 获得 ， 下 面 是 其 中 的 一 部 分 信息 : 























root root 4:60 —>../../devices/virtual/tty/tty60 


root root 4:61 —>../../devices/virtual/tty/tty61 
root root 4:62 —».. /. . / devices/ virtual/tty/tty62 
root root 4:63 —».. /. . / devices/ virtual/tty/tty63 

. / devices/ platform/serial8250/tty/ttySO 
. / devices/ platform/serial8250/tty/ttyS1 
. / devices/ platform/serial8250/tty/ttyS2 
. / devices/ platform/serial8250/tty/ttyS3 


. / devices/ platform/serial8250/tty/ttyS4 


root root 4:64 —».. 
root root 4:65 一 >.. 
root root 4:66 —».. 


root root 4:67 —».. 


pu MNT 


root root 4:68 —».. 


其 中 包含 主 设备 号 、 次 设备 号 和 路 径 等 信息 ， 从 中 可 以 了 解 具体 的 设备 分 类 和 设备 号 的 
划分 。 详 细 的 设备 分 类 信息 可 以 通过 Documentation/devices. txt 文件 获得 。 后 面 会 对 部 分 设 
备 进行 详细 的 分 析 。 





























5.4 块 设备 (block device) 


5.4.1 块 设备 特点 和 需求 


块 设备 的 数据 特点 是 有 固定 的 数据 单元 ( 块 )， 可 以 随机 存 取 。 块 设备 是 非 易 失 存 储 设 
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备 ， 其 上 的 数据 是 可 以 回 读 的 ， 只 要 数据 没有 改变 ， 任 何 时 间 读 取 同 一 位 置 的 数据 意义 都 是 
相同 的 。 

非 易 失 存储 设备 很 重要 的 功能 是 存放 用 户 和 系统 的 数据 ， 而 用 户 和 系统 的 数据 一 般 依赖 
于 文件 系统 ， 通 过 块 设备 对 非 易 失 存储 设备 进行 操作 ， 有 具体 的 数据 结构 化 和 组 织 留 给 文件 系 
统 进行 管理 。 块 设备 就 是 文件 系统 的 物理 基础 。 

从 系统 的 角度 ， 块 设备 作为 系统 数据 的 存放 设备 ， 相 应 的 性 能 是 十 分 重要 的 。 由 于 可 以 
随机 访问 ， 块 设备 的 管理 就 要 比 字 符 设备 复杂 的 多 。 基 于 这 些 原因 在 块 设备 框架 的 设计 过 程 
中 效率 是 必须 要 考虑 的 因素 ， 字 符 设备 更 多 考虑 的 是 延 时 间 题 ， 而 块 设备 则 是 要 考虑 整个 系 
统 的 性 能 。 为 了 提高 整体 性 能 ， 比 较 普 遍 的 方法 是 在 内 存 中 建立 buffer 通过 缓冲 来 提高 性 
能 ， 这 样 虽然 提高 了 系统 的 复杂 度 ， 但 是 为 了 性 能 也 是 值得 的 。 另 外 有 了 缓冲 之 后 写 操作 的 
实时 性 要 求 降低 ， 而 读 操 作 在 性 能 方面 同样 有 延 时 要 求 。 针 对 整体 性 能 的 提升 ， 系 统 有 对 数 
据 进 行 批 处 理 操作 的 需求 。 


5.4.2 块 设备 核心 数据 结构 及 操作 


1. 整体 框架 
要 了 解 块 设备 首先 要 从 系统 层面 了 解 块 设备 所 在 的 位 置 和 上 下 层 的 关系 ， 如 图 5-20 
所 示 。 
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Buffter/page cache 


y Y 
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K5-20 块 设 备 在 系统 中 层次 关系 


从 图 5-20 可 见 ， 块 设备 层 既 可 以 作为 裸 设 备 来 供应 用 层 使 用 ， 也 可 以 作为 物理 文件 系 
统 的 承载 设备 与 文件 系统 进行 关联 。 为 了 提升 整个 系统 的 性 能 ， 在 块 设备 层 之 上 增加 了 
buffer 层 来 缓冲 数据 ，buffer 是 缓存 在 内 存 中 ， 所 以 物理 上 会 将 多 个 buffer AZ page 中 ， 
整体 形成 page cache。 这 种 架构 满足 了 之 前 涉及 的 需求 ， 并 兼顾 灵活 性 与 整体 的 性 能 。 

块 设备 层 的 内 部 设计 同样 要 考虑 性 能 ， 从 整体 上 块 设备 的 内 部 框架 如 图 5-21 所 示 。 从 
图 5-21 可 见 ， 块 设备 的 框架 层次 还 是 很 灵活 的 ， 可 以 为 了 满足 某 种 需求 ， 设 计 虚 拟 块 设备 
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实现 如 负载 均衡 等 高 级 的 功能 ; 为 了 整体 性 能 和 吞吐 量 ， 增 加 了 IO scheduler 层 来 优化 物理 
设备 的 读 写 性 能 ; 也 可 以 跳 过 10 scheduler 层 直 接 进 行 块 设备 操作 。 总 体 上 讲 ， 这 种 内 部 杠 
架 可 以 把 分 层 的 驱动 综合 起 来 实现 复杂 的 功能 。 
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Al5-21 块 设备 内 部 框架 





2. 核心 管理 实体 

从 整体 的 层次 上 看 ， 块 设备 需要 有 针对 文件 系统 和 VES 的 接口 实体 ， 另外 还 需要 管理 
生命 周期 的 设备 模型 相关 实体 以 及 驱动 管理 实体 。 除 此 之 外 块 设备 的 数据 是 以 块 为 单位 ， 自 
然 在 操作 上 要 有 相关 的 单位 操作 管理 实体 以 及 管理 方法 ， 这 些 就 形成 了 驱动 。 

针对 以 上 的 分 析 ， 来 看 看 Linux 内 核 的 具体 实现 ， 块 设备 主要 管理 实体 及 系统 关系 如 
图 5-22 所 示 。 

图 5-22 中 主要 涉及 的 管理 实体 是 block_device hd. struct 和 gendisk。 与 操作 相关 的 是 re- 
quest 和 bio 结构 ， 另 外 图 中 还 涉及 与 buffer/page cache 的 关系 。buffer/page cache 是 将 文件 系 
统 等 非 内 存 空 间 的 数据 存放 在 内 存 页 面 中 ， 所 以 在 系统 结构 上 通过 内 存 管理 的 page 以 及 地 址 
转换 管理 address space. (可 以 根据 不 同 的 内 容重 载 为 不 同 的 管理 操作 ) 实现 这 部 分 的 管理 ， 块 
设备 的 数据 单元 块 在 内 存 中 通过 buffer head 进行 管理 ,一 个 物理 页 中 会 存放 多 个 块 ， 而 物理 
页 的 管理 实体 page 会 通过 链表 对 buffer head 进行 管理 ， 进 而 管理 其 中 存放 的 块 。 而 page 中 的 
private 和 标识 共同 表示 其 中 管理 的 是 buffer_head 链表 。buffer_head 和 page 是 通过 attach_page_ 
buffers 来 进行 关联 该 函数 会 通过 set. page. private 来 设置 page 的 private 属性 ， 这 样 通 过 page, 
buffer_head 以 及 address_space 就 实现 了 buffer/page cache 的 管理 。 涉 及 块 设备 层 和 上 层 之 间 的 
绥 冲 操作 也 可 以 通过 该 框架 实现 ， 只 要 实现 不 同 的 address. space 操作 即 可 。 

物理 的 块 设备 〈 如 硬盘 ) 通常 可 以 进行 分 区 ， 而 不 同 分 区 在 用 户 看 来 是 不 同 的 设备 。 硬 
盘 本 身 同样 是 设备 ， 这 样 实际 就 有 设备 层次 ， 需 要 在 文件 系统 层面 能 够 了 解 这 种 设备 层次 ， 是 
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图 5-22 块 设 备 层 各 实体 及 系统 关系 框图 


设备 管理 的 需求 ， 否 则 用 户 无 法 了 解 某 个 分 区 及 物理 磁盘 的 关系 。 这 就 要 求 块 设备 对 应 的 文件 
系统 相关 的 管理 实体 能 够 表现 这 种 层次 关系 。 同 一 个 物理 磁盘 ， 相 关 的 操作 没有 差别 ， 与 之 上 
的 文件 系统 没有 关系 ， 所 以 驱动 管理 实体 并 不 需要 每 个 分 区 有 一 个 ， 为 了 实现 数据 的 批 处 理 操 
作 相 应 的 操作 数据 需要 以 链表 的 形式 存在 。 再 者 在 块 设备 层 与 文件 系统 的 接口 管理 实体 中 直接 
表示 硬件 的 分 区 信息 是 不 合适 的 ， 所 以 也 要 一 个 实体 进行 物理 分 区 的 管理 ， 分 区 本 身 就 是 实际 
的 逻辑 设备 ， 所 以 也 会 将 设备 模型 相关 的 管理 归 入 其 中 。 以 上 的 管理 都 是 通过 管理 实体 block _ 
device, hd struct 和 gendisk 来 实现 的 。 它 们 之 间 各 种 关系 的 细节 如 图 5-23 所 示 。 

从 图 5-23 可 见 ， 文 件 系统 中 的 设备 层次 由 block device 来 实现 ， 了 驱动 的 管理 实体 通过 
gendisk 来 进行 管理 ，hd_struct 进行 物理 的 分 区 管理 ， 同 时 为 设备 模型 的 接口 。 这 样 各 种 结 
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构 的 功能 就 明确 了 ， 接 下 来 看 看 细 方 。 


bd_contains 
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bd_contains 







bd_disk 





block_device 
(disk) 







gendisk request_queue 







block_device 
(partition) 





part 


hd_struct hd_struct hd_struct hd_struct 


Al5-23 块 设备 内 部 管理 实体 关系 框图 








先 看 看 block device 的 主要 信息 ; 


struct block_device } 





/设备 号 

dev_tb d_dev; / * not a kdev_t—it’s a search key */ 
// 文 件 系统 相关 关联 接口 

struct inode * bd_inode ; /* will die */ 


struct super block * bd, super; 


// 打 开 次 数 

int bd_openers; 

struct mutex bd_mutex ; / * open/close mutex * / 
struct list_head bd_inodes ; 

void * bd. claiming; 





// 块 设备 会 和 VFS 以 及 具体 文件 系统 中 的 管理 实体 关联 
// 这 里 bd_holder 表明 某 个 时 间 与 哪个 实体 关联 

















void * bd. holder; 

int bd. holders; 
#ifdef CONFIG_SYSFS 

struct list_head bd holder. list ; 


#endif 














// 使 用 此 属性 表示 设备 的 层次 , 子 分 区 指向 容器 的 设备 block_device 
struct block_device *bd_contains; 

// 块 大 小 

unsigned bd_block_size ; 

/物理 分 区 信息 
struct hd, struct * — bd, part; 








/ * number of times partitions within this device have been opened. * / 








unsigned bd. part. count ; 
int bd. invalidated ; 
// 驱 动 管理 实体 

struct gendisk * bd_disk; 

// 系 统 整体 的 block. device 管理 
struct list_head bd_list; 


l; 





从 其 中 的 属性 可 见 与 VFS 以 及 具体 的 文件 系统 都 会 有 关联 ， 这 点 不 难 理解 。 设 备 本 身 
可 以 作为 文件 提供 给 用 户 ， 另 外 块 设备 还 是 具体 的 文件 系统 的 承载 ， 这 两 点 都 要 体现 ， 就 都 
需要 关联 彼此 了 。 

接 下 来 看 看 hd_ struct 的 主要 信息 : 
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struct hd_struct | 
// 物 理 分 区 信息 


sector_t start_sect; 





sector_t nr_sects; 
sector t alignment, offset ; 

unsigned int discard. alignment ; 
// 设 备 模型 关联 信息 


struct device __dev; 





struct kobject * holder. dir; 
int policy, partno; 
// 物 理 分 区 表 原 信息 


struct partition_meta_info * info; 





l; 











其 中 不 仅 包含 了 物理 分 区 的 信息 还 与 设备 模型 有 关联 ， 毕 竞 分 区 就 是 对 应 着 物理 的 设备 。 相 
应 的 设备 模型 的 管理 主要 是 在 设置 _dev 上 ， 在 add, partition 中 的 设置 如 下 : 

















device_initialize( pdev) ; 

pdev —> class = &block_class; 
pdev —> type = &part_type; 
pdev -> parent = ddev; 


err = blk_alloc_devt(p, &devt) ; 
if( err) 
goto out. free info; 


pdev -> devt = devt ; 
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可 见 相关 操作 时 初始 化 device 实体 并 分 配 设备 号 ， 其 中 device 关联 特定 的 part. type 类 
型 ， 生 命 周 期 结束 时 可 以 释放 相关 的 空间 。 整 个 磁盘 又 是 如 何 与 设备 模型 相关 联 呢 ? 这 就 需 
要 看 看 gendisk : 

















struct gendisk | 
/设备 号 相关 
int major; / * major number of driver * / 
int first_minor; 
int minors ; / * maximum number of minors, = 1 for disks that can’ t be 


partitioned. */ 


char disk name[ DISK NAME, LEN] ;/ * name of major driver * / 
char * ( * devnode) (struct gendisk * gd, mode t * mode) ; 











// 实 际 的 分 区 设备 表 , 其 中 包含 hd_struct 
struct disk_part_tbl _ rcu * part_tbl; 
// 用 于 表示 disk 的 物理 信息 以 及 与 设备 模型 关联 


struct hd, struct part0 ; 





























// 物 理 disk 的 控制 操作 接口 
const struct block_device_operations * fops; 
// 运 行 时 设备 需要 操作 数据 的 队列 及 操作 接口 ,主要 是 数据 流 的 操作 


struct request_queue * queue; 





void * private_data; 


int flags; 
struct device * driverfs_dev; // FIXME: remove 


struct kobject * slave, dir; 


E 


nj LERRA T struct hd. struct part0; 这 样 既 有 了 整体 disk 的 物理 信息 又 可 以 与 设备 模 
型 相关 联 。 在 alloc_disk 中 会 调用 alloc_disk _node, 其 中 包含 如 下 代码 : 





disk_to_dev( disk) —» class = &block_class; 
disk to dev(disk) -> type = &disk_type; 
device, initialize( disk to. dev( disk ) ) ; 


这 里 设置 的 设备 模型 相关 类 型 为 disk_type， 可 以 对 disk 进行 生命 周期 管理 ， 在 必要 的 
时 候 可 以 释放 其 中 分 区 的 信息 。 

3. 驱动 管理 及 块 设 备 驱动 流程 

qu ea Lane kobj map 来 实现 的 ，kobj_map 中 的 内 容 之 前 在 字符 
设备 中 已 经 进行 了 介绍 ， 下 面 看 看 块 设备 层 是 如 何 使 用 它 完 成 驱动 管理 的 。 
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驱动 管理 要 涉及 设备 号 的 范围 及 管理 实体 ， 块 设备 层 将 其 封装 为 blk_register_region ， 细 
TUF: 








void blk_register _region( dev, t devt, unsigned long range, struct module * module, 
struct kobject * ( * probe) (dev. t, int ** , void * ) ， 
int( * lock) (dev. t, void * ), void * data) 


kobj map( bdev. map, devt, range, module, probe, lock, data) ; 


} 
下 面 来 看 看 具体 的 管理 实体 是 什么 ?相关 在 add. disk 中 的 实现 如 下 : 


void add, disk( struct gendisk * disk) 
| 
struct backing dev, info * bdi; 
dev. t devt ; 


int retval; 


// 4r lib disk 的 设备 号 
retval = blk_alloc_devt( &disk -> part0, &devt) ; 
if( retval) 
i WARN. ON(1) ; 
return ; 
} 
disk_to_dev( disk) —» devt = devt; 


/ * —»major and —> first, minor aren t supposed to be 
* dereferenced from here on, but set them just in case. 
*/ 

/记录 设备 号 

disk -> major = MAJOR( devt) ; 

disk -> first, minor = MINOR( dewt) ; 





/ * Register BDI before referencing it from bdev * / 
bdi = &disk -> queue -> backing_dev_info; 
bdi_register_dev(bdi, disk_devt( disk) ) ; 














/这 里 注册 驱动 管理 实体 
blk register region( disk_devt(disk) ，disk -> minors, NULL, 


exact_match, exact_lock, disk) ; 














// [8] sys 文件 注册 相关 信息 
register disk( disk) ; 
// Vi] sys 文件 注册 数据 流 的 操作 信息 ,提供 操作 接 









































E 
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blk register queue( disk) ; 


retval = sysfs create _link( &disk, to dev( disk) -> kobj, &bdi -> dev -> kobj, 
" bdi" ) ; 
WARN_ON(retval ) ; 
} 


从 代码 分 析 可 见 ， 驱 动 管理 实体 是 gendisk ， 在 注册 驱动 管理 实体 的 同时 还 向 sys 文件 系 
统 注 册 一 些 属 性 ， 以 便 运 行 时 可 以 进行 相关 设置 。 

块 设备 驱动 管理 的 子 设备 号 由 具体 的 块 设 备 进行 设置 ， 因 为 这 和 其 能 力 相 关 ， 块 设备 层 
提供 了 alloc_disk 接口 进行 相关 操作 。 

驱动 管理 实体 gendisk 的 细节 如 图 5-24 所 示 。 




































































block_device_operations 
open() 
release() 
pow ioctl() 
media changed() 
gendisk revalidate() 
getgeo() 
major ER 
first minor request 
minors 
disk name sector 
fops request queue current nr sectors 
quene » buffer 
private data request fn LA rq disk 
i List of requests 
cad i 2 
foo device 

















从 图 5-24 可 见 ， 其 中 主要 包括 设备 的 控制 操作 接口 block_device_operations， 以 及 与 设 
备 数 据 流 相关 的 数据 队列 及 操作 。block_device_operations 中 主要 是 对 设备 打开 、 关 闭 ， 以 及 
换 盘 等 控制 操作 的 接口 。 这 样 设计 的 原因 是 : 块 设备 是 文件 系统 的 物理 基础 ， 而 物理 文件 系 
统 不 会 调用 VFS 中 的 文件 接口 〈 这 样 做 使 得 层次 混乱 ) ， 所 以 相关 的 控制 操作 通常 会 在 块 设 
备 层 中 进行 封装 ， 比 如 blkdev_get 就 会 进行 设备 open 的 操作 ， 这 样 可 以 为 上 层 各 种 需求 提 
供 统一 的 接口 。 

块 设备 数据 流 请 求 的 具体 关系 以 一 个 例子 进行 说 明 ， 如 图 5-25 所 示 。 

图 5-25 中 的 一 次 操作 的 请 求 是 读 取 连续 16KB 的 数据 ， 由 于 Linux 内 核 中 将 sect 定义 为 
512 B， 所 以 是 32 个 sect。 相 应 的 请 求 拆 成 两 个 bio 进行 操作 ， 每 个 bio 为 8KB 的 操作 ， 对 
应 到 内 存 的 两 个 page， 相 应 分 配 bio. vec 的 数组 为 2 会 关联 到 两 个 物理 页 面 的 管理 实体 。 实 
际 的 操作 就 是 在 页 面 与 bio 之 间 进 行 ， 通常 这 些 块 设备 DMA 的 操作 通过 散 列 式 DMA 的 方式 
实现 ， 以 提高 整体 的 性 能 。 
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0 i 4096 0 4096 
bio 7 bio 
m| vec 0 4096 0 4096 vec 
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» bio ID CL bio 
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1024 
E 5-25 块 设备 数据 请 求 例子 
针对 块 设备 的 数据 操作 流程 ， 块 设备 层 统一 提供 了 操作 单元 ho， 相应 的 起 始 操作 接口 
是 submit_bio， 从 submit. bio 到 请 求 队列 的 流程 如 图 5-26 所 示 。 




















submit_bio() mm/mpage.c 
Se include/linux/blkdev.h 
generic_make_request(bio) block/elevator.c 











X BLK_TA_QUEUE block/ll rw/blk.c 





block/as-iosched.c 











q-2make request fn(q,bio) 


Y 
. make request(q,bio) 


\ 


elv_merge(q,req, bio) 


(eue ee 


q->back_merge_fn() init_request_from_bio() 
































BLK_TA_SLEEPRQ 

















x J BLK_TA_GETRQ 


l| merge requests fn() get request wait() gere tec 
BLK TA MERGE d E 


elv may queue() 








































































































elv merged request() add request() 
ENS SE get request() 
e-»ops-»elevator merged fn() . elv add request() SS 
J current_io_context() 
elv_insert() blk_alloc_request() 




















BLKTA INSERT — 


E-»ops-»elevator add req fn(g,rq) 


IO Scheduler | 


Request Queue 4 
Device Driver 


5-26 submit bio 到 请 求 队列 流程 
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从 图 5-26 可 见 ， 在 真正 处 理 请 求 之 前 是 可 以 对 请 求 进 行 合 并 等 操作 的 ， 这 样 保证 最 终 
执行 的 请 求 尽 可 能 的 集中 ， 以 减少 如 机 械 硬 盘 等 有 机 械 件 的 块 设备 的 机 械 操 作 。 
通常 情况 下 具体 块 设备 相 应 的 请 求 处 理 流程 如 图 5-27 所 示 。 











| q->make_request_fn() | include/linux/blkdev.h 
block/elevator.c 
Bocki hike 
BLK TA PLUG block/as-iosched.c 


—eh-add requesi() Disk request queue without an I/O scheduler 
elv_insert() 

list_add_tail() 

q->request_fn() 


BLK_TA_INSERT 




























ide_do_request() 


=L L 


| > 



























































| rq=__elv_next_request(q) 




















ey 
start_request() 





BLK_TA_ISSUE(D) 


interrupt for completion 














图 5-27 一 般 块 设备 请 求 处 理 流程 





从 图 5-27 可 见 ， 上 层 下 发 的 请 求 是 完全 按照 顺序 进行 处 理 的 ， 其 中 请 求 队列 中 的 re- 
quest. fn 通常 是 唤醒 具体 块 设备 的 驱动 进程 进行 实际 的 请 求 处 理 ， 这 样 将 上 层 与 驱动 分 开 在 
不 同 的 执行 实体 执行 ， 可 以 通过 对 数据 进行 批 处 理 操作 ， 从 而 提高 整体 的 性 能 。 

从 系统 的 角度 ，I0 性 能 除了 吞吐 量 外 ， 还 要 考虑 不 同 应 用 10 请 求 的 响应 延 时 。 如 果 只 
是 按照 顺序 进行 块 设备 的 请 求 处 理 并 不 能 很 好 地 满足 各 种 响应 延 时 的 需求 ， 所 以 需要 在 请 求 
执行 过 程 中 加 入 调度 的 机 制 ， 就 是 IO scheduler， 来 提升 整体 的 性 能 。 由 于 这 些 都 是 对 实际 
操作 请 求 的 调整 ， 所 以 都 被 包含 在 request. queue 中 ,不同 的 IO scheduler 方式 由 struct eleva- 
tor type 来 定义 ， 主 要 的 操作 接口 包含 在 struct. elevator, ops P, request, queue 如 果 使 用 IO 
Scheduler 则 逻辑 上 有 两 套 queue， 一 个 是 IO scheduler 使 用 的 queue; 另 一 个 是 物理 驱动 操作 
的 queue。 具 体 的 流程 如 图 5-28 所 示 。 

从 图 5-28 可 见 ， 真 正 对 请 求 的 操作 顺序 是 会 依据 之 前 的 10 操作 重新 调整 顺序 的 ， 作 为 
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| q->make_request_fn() | include/linux/blkdev.h 





block/elevator.c 
add request() block/ll rw/blk.c 
BLK TA PLUG block/as-iosched.c 


elv add request 

一 ev_add_request() Disk request queue with an I/O scheduler 
elv insert() 
e->ops->elevator_add_req_fn(q,rq) 


q->request_fn() 






























BLK_TA_INSERT 





ide_do_request() 


| elv_next_request() | 


| rq- elv next request(q) | 
y 
| e->ops->elevator_dispatch_fn() 
ef 
start_request() 

























































































BLK_TA_ISSUE(D) 


interrupt for completion 














图 5-28 带 io scheduler 的 块 设备 请 求 处 理 流 程 








内 核 块 设备 层 可 以 实现 一 个 反馈 系统 ， 从 而 尽力 满足 所 有 用 户 的 性 能 需求 ， 提 高 整体 的 10 
性 能 。 当 然 不 会 有 对 所 有 情况 都 满足 的 调度 方法 ， 所 以 Linux 内 核 提 供 了 很 多 种 IO scheduler 
方法 ， 如 CFQ, Deadline 等 以 适应 不 同 的 需求 。 系 统 可 以 通过 elevator_switch 来 进行 不 同调 
度 算 法 之 间 的 切换 。 由 于 10 scheduler 是 与 算法 紧密 相关 的 这 里 就 不 进行 详细 的 分 析 。 

4. 块 设 备 驱 动 初始 化 

针对 块 设备 驱动 ， 块 设备 层 提 供 了 很 多 接口 包括 如 何 操 作 请 求 队列 (start，stop， 延 时 
操作 等 ) ， 还 提供 了 默认 生成 request 的 接口 __ make_request， 但 是 只 有 一 个 接口 request_fn 需 
要 由 驱动 提供 ， 前 面 提 到 了 该 接口 是 具体 唤醒 驱动 请 求 处 理 的 函数 ， 也 是 和 具体 驱动 关系 最 
紧密 的 部 分 ， 相 关 的 初始 化 就 是 要 将 驱动 特定 的 request. fn 接口 加 入 request. queue 中 ，Linux 
内 核 通过 blk_init_queue 生成 包含 驱动 特定 接口 的 request_queue 来 实现 该 功能 。 具 体 驱 动 的 
初始 化 流程 如 图 5-29 所 示 。 

从 图 5-29 可 见 ， 对 于 具体 的 块 设备 驱动 中 最 重要 的 两 部 分 就 是 request. fn AIP IT. re- 
quest, fn 负责 下 发 请 求 并 唤醒 处 理 罗 辑 ; 中 断 则 负责 处 理 之 后 的 流程 唤醒 。 两 者 完整 的 结合 
实现 整体 数据 操作 。 
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ide_generic_init() 











\ 








ideprobe_init() 





N 





hwif. init() 











N 








init_irq() 








b cte 





request_irq(hwif->irq,&ide_intr,---) 








nd 








ide init queue() 








Se 








blk_init_queue_node(do_ide_request,--- 





) 





I 








q->request_fn=rfn 








register I/O request dispatcher 


SA 


drivers/ide/ide-generic.c 
drivers/ide/ide-probes.c 
drivers/ide-io.c 


block/ll rw/blk.c 








ide intr() 














do ide request() 
















ide do request() 

















在 块 设备 框架 


图 5-29 具体 驱动 的 初始 化 流程 
层 ， 具 体 的 块 设备 驱动 初始 化 一 般 按 照 以 下 流程 实现 : 首先 需要 通过 al- 





loc, disk 来 分 配 驱 动 管理 实体 gendisk; 然后 将 blk_init_queue 生成 的 设备 自身 requests queue 
加 入 到 gendisk 中 ; 最 后 通过 add. disk 来 将 驱动 管理 实体 加 入 系统 进行 管理 。 
以 通过 驱动 进行 操作 了 。 


5.4.3 BM 


块 设备 的 类 型 同样 是 通过 设备 号 进 


ev， 接 口 定 义 如 下 : 
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行 管理 的 ， 


int register_blkdev( unsigned int major, const char * name) 


可 见 块 设备 并 没有 通过 








二子 设备 号 进行 


这 样 系统 就 可 


块 设备 注册 设备 号 的 接口 是 register_blk- 


， 毕 况 块 设备 类 型 的 数量 与 字符 设备 还 
距 的 。 所 以 了 解 系统 块 设备 的 分 类 只 1 需要 看 /proo/devices 即 可 。 细 节 如 下 : 


Block devices; 


1 ramdisk 
259 blkext 
7 loop 
8 sd 
9 md 
11 sr 
65 sd 
66 sd 
67 sd 
68 sd 
69 sd 
70 sd 
71 sd 
128 sd 
129 sd 
130 sd 
131 sd 
132 sd 
133 sd 
134 sd 
135 sd 
251 zram 
252 device — mapper 
253 virtblk 
254 mdp 


从 中 可 见 有 很 多 sd, sd 是 硬盘 的 总 称 ， 有 各 种 各 样 的 硬盘 如 IDE、SCSI 等 。 具 体 分 类 
信息 可 以 通过 Documentation/devices. txt 文件 获得 。 后 面 会 对 部 分 设备 进行 详细 分 析 。 











5.5 电源 管理 


5.5.1 电源 管理 特点 和 需求 
Linux 内 核 在 设计 之 初 并 没有 考虑 电源 管理 ， 但 是 随 着 节能 需求 不 断 提 高 ， 特 别 是 终端 
类 产品 迅速 发 展 ， 对 于 电源 管理 的 需求 越 来 越 强烈 ，Linux 内 核 也 提供 了 电源 管理 功能 。 
电源 管理 相关 的 硬件 知识 之 前 已 经 有 了 介绍 ， 对 软件 来 说 基本 上 就 是 利用 硬件 的 能 力 实 





现 系统 “能 睡 


就 睡 















































”， 设 备 能 降低 频率 就 降低 频率 ， 另 外 还 要 满足 用 户主 动 的 电源 管理 需 





求 。 进 行 这 些 操 作 的 前 提 是 要 能 保证 系统 和 设备 正常 运行 。 
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5.5.2 电源 管理 核心 框架 介绍 


Linux 内 核 的 电源 管理 部 分 在 X86 架构 上 有 ACPI (高 级 配置 与 电源 管理 接口 ) ， 但 是 1 
大 的 舱 入 式 设备 并 不 支持 ACPI， 而 对 钥 入 式 设备 来 说 电源 管理 的 需求 更 强烈 ， 所 以 急需 相 
关 的 功能 实现 。 考 虑 到 电源 管理 的 需求 涉及 处 理 需 和 各 种 设备 ， 一 方面 是 处 理 器 尽 可 能 减少 
功 耗 ， 另 一 方面 是 设备 尽 可 能 减少 功 耗 。 减 少 功 耗 的 功能 框架 各 种 各 样 ， 一 种 功能 框架 是 不 
能 满足 电源 管理 的 需求 的 。 所 以 Linux 内 核 将 电源 管理 分 成 不 同 的 功能 模块 来 实现 ， 这 样 通 
过 各 个 功能 模块 整体 工作 来 满足 电源 管理 的 需求 。Linux 内 核电 源 管 理 功能 如 图 5-30 所 示 。 
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BI 5-30 Linux 电源 管理 各 个 功能 
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JARI 5-30 可 见 Linux 内 核 的 电源 管理 功能 有 与 处 理 器 相关 的 CPUIdle 和 CPUFreq, +44 
与 设备 相关 的 runtime pm， 男 外 还 有 与 整个 系统 待机 时 SLM (standby leakage management) 
相关 的 低 功 耗 电源 管理 功能 。 但 并 不 是 只 有 这 些 功 能 ， 在 时 间 管 理 中 的 dynamic tick 也 属于 
降低 功 耗 的 功能 。 下 面 分 别 对 这 些 功 能 框架 进行 介绍 。 

1. CPUIdle 

在 初始 化 的 时 候 有 过 介绍 ， 系 统 在 没有 任务 需要 调度 的 时 候 会 执行 cpu_idle， 使 处 理 器 
处 于 休息 状态 ， 其 中 系统 提供 了 pm idle 接口 实现 各 种 idle 的 省 电 功 能 。CPUIdle 会 将 其 改 
为 自己 的 接口 cpuidle_idle_call， 这 样 在 内 核 进 入 idle 时 就 会 调用 相应 的 接口 ， 从 而 进入 合适 
的 状态 。 接 下 来 分 析 一 下 相关 的 功能 : 











static void epuidle idle call( void) 


| 














// 首 先 获得 处 理 器 特定 的 设备 包含 属性 和 接口 信息 
struct cpuidle_device * dev =__get_cpu_var( cpuidle devices) ; 
struct cpuidle state * target state; 


int next, state ; 
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如果 需要 进行 设备 进入 idle 的 准备 操作 
if( dev -> prepare) 





dev —> prepare( dev) ; 


/ * ask the governor for the next state * / 








// 通 过 设置 的 主管 逻辑 以 及 设备 的 QoS 选择 合适 的 状态 














next, state = cpuidle_curr_governor —> select( dev) ; 











// 如 果 发 现 需 要 调度 , 则 不 应 该 睡眠 了 ,由 于 进入 时 关中 断 ,所 以 这 里 开 中 断 








if(need_resched( ) ) | 
local_irq_enable( ) ; 


return; 


target, state = &dev —> states[ next. state | ; 


/ * enter the state and update stats * / 


// 进 入 睡眠 操作 并 进行 统计 


dev —> last state = target. state ; 








dev -> last residency = target, state —> enter( dev, target. state) ; 


if( dev —> last, state) 


target, state = dev —> last, state; 


target, state —» time + = (unsigned long long) dev -> 


target. state 一 > usage ++ ; 


last, residency ; 


/ * give the governor an opportunity to reflect on the outcome ** / 











T 











/通知 主管 相关 操作 ,使 得 其 算法 得 到 相关 信息 


if( cpuidle_curr_governor -> reflect) 








cpuidle_curr_governor -> reflect ( dev) ; 


trace_power_end(smp_processor_id() ) ; 


| 














分 析 代 码 可 见 ， 具 体 的 驱动 要 提供 多 种 状态 ， 这 些 状态 是 和 QoS 相关 的 。 所 谓 QoS 就 






































是 指 对 于 idle 来 说 不 是 简单 地 睡 就 可 以 了 ， 要 考虑 醒 来 工作 是 否 可 以 正常 ， 例 如 进入 不 同 的 


状态 系统 睡眠 和 唤醒 延 时 是 不 同 的 ， 而 idle 只 是 短 时 间 进 入 低 功 耗 ， 相 关 的 任务 更 重要 ， 不 














能 为 了 进入 功 耗 更 低 的 状态 而 影响 正常 的 工作 ， 这 就 需 





标记 唤醒 的 时 间 ， 由 governor 来 根据 当前 的 系统 状态 选择 








好 又 不 能 影响 工作 。CPUIdle 睡眠 示意 如 图 5-31 所 示 。 

















要 QoS 机 制 。 在 标记 状态 的 同时 要 
合适 的 低 功 耗 状 态 进 入 ， 既 要 休息 








从 图 5-31 可 见 ， 系 统 要 考虑 进入 哪 种 状态 与 能 够 四 








EHR AYES TA] | sleep 和 wakeup 延 时 都 























是 相关 的 ， 能 睡眠 的 时 间 越 长 越 应 该 进入 更 高 级 别 的 低 














个 处 理 器 的 下 一 次 tick 的 时 间 来 决定 可 进入 低 功 耗 的 时 间 ， 从 而 进行 选择 。 








功 耗 状态 。 menu governor 是 通过 每 
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具体 的 设备 驱动 会 在 SoC 电源 管理 部 分 进行 讲解 。 


2. CPUFreq 


CPUidle 电源 管理 示意 图 
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WAKEUP 
EVENT 
































CPUFreq 就 是 实现 处 理 器 的 频率 变化 ， 其 中 会 涉及 DVFS 来 降低 功 耗 ， 相 关 的 硬件 原理 
之 前 已 经 介绍 。 这 里 对 Linux 内 核 的 软件 实现 进行 分 析 。 

在 介绍 无 关 性 实现 的 时 候 ， 已 经 介绍 了 CPUFreq 的 框架 (ULAR 3 221), TE CPUFreq 中 
不 管 根据 什么 原则 ， 是 监视 系统 状态 也 好 还 是 用 户 设置 也 好 ， 在 选择 了 相应 的 频率 等 级 后 最 


终 都 是 通过 








cpufreq_driver_target 来 进行 频率 设置 的 ， 其 中 会 调用 具体 的 设备 target 接口 进 
入 相应 的 频率 等 级 。 具 体 的 驱动 同样 会 在 SoC 电源 管理 部 分 进行 讲解 。 





这 里 看 看 governor 的 实现 ， 主 要 介绍 ondemand governor。 流 程 图 如 图 5-32 所 示 。 
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ondemand 流程 医 

















从 图 5-32 FLL, ondemand governor 主要 是 监控 CPU 的 使 用 率 是 否 超过 一 定 的 值 ， 如 果 
是 就 提高 主 频 ， 如 果 使 用 率 很 低 就 降低 主 频 ， 从 而 实现 根据 使 用 率 的 动态 调节 以 达到 按 需 使 
用 的 功能 。 相 关 的 参数 配置 在 /sys/ devices/system/cpu/cpu0/cpufreq/ 日 录 下 ， 可 以 根据 需要 
进行 设置 。 

3. SLM 

这 两 部 分 功能 都 和 设备 相关 。 首 先 来 看 看 设备 模型 相关 的 初始 化 部 分 ， 如 图 5-33 
所 示 。 
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device_initialize(dev) device add(dev) 


device_pm_init(dev) set_ dev_nodel() device_pm_add(dev) 
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图 5-33 设备 模型 电源 管理 相关 初始 化 








从 图 5-33 可 见 ， 其 中 涉及 了 设备 Runtime pm 的 相关 初始 化 ,但 是 SLM 的 操作 并 不 明 
显 。 其 实 设备 的 SLM 相关 操作 已 经 隐 含 在 device 添加 过 程 device. pm. add 中 ， 思 考 一 下 ， 
SLM 操作 时 要 进入 某 种 待机 状态 ， 其 中 会 涉及 所 有 的 设备 ， 自 然 将 其 放 和 人 系统 的 设备 增加 
过 程 中 。 这 样 系统 的 SLM 操作 就 可 以 通过 设备 模型 统一 管理 了 。 下 面 来 看 看 细节 : 

















void device_pm_add(struct device * dev) 
| 
pr_debug( " PM; Adding info for % s:%s\n", 
dev -> bus ? dev -> bus -> name : "No Bus", 
kobject_name( &dev -> kobj) ) ; 
mutex, lock ( &dpm list, mix) ; 
if( dev -> parent) | 
if( dev -> parent —» power. status >= DPM, SUSPENDING ) 
dev. warn( dev, "parent % s should not be sleeping Yn" , 
dev. name( dev —> parent) ) ; 
} else if(transition started) | 
J * 
* We refuse to register parentless devices while a PM 


* transition is in progress in order to avoid leaving them 
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* unhandled down the road 
*/ 


dev. WARN( dev, "Parentless device registered during a PM transaction n" ) ; 








是 将 设备 加 入 dpm. list 设备 功 耗 管理 列表 进 




















// XX HB 
list, add, tail( &dev -> power. entry, &dpm list) ; 


mutex, unlock ( &dpm list, mix) ; 


| 
既然 所 有 的 设备 都 会 通过 device, add 添加 到 设备 模型 中 进行 管理 ,那么 相应 的 也 会 加 入 


到 设备 功 耗 管理 列表 中 进行 管理 
WBA ABU PEAR 村 机 状态 呢 ? 这 就 要 看 sys 文件 系统 了 ， 如 图 5-34 所 示 。 
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图 5-34 待机 控制 框图 








从 图 5-34 可 见 ，/sys/power 目录 下 的 state 文件 用 于 设置 具体 的 待机 状态 。 通 过 enter_ 


state 即 可 进入 相应 的 状态 ， 最 终 要 进入 待机 suspend 状态 才 会 调用 dpm_suspend_noirq。 下 面 
来 看 看 实现 细节 : 


int dpm_suspend_noirq( pm, message. t state) 


| 


struct list_head list; 
// 记 录 操 作 时 间 
ktime_t starttime = ktime_get( ) ; 


int error =0; 
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INIT. LIST. HEAD( &list) ; 

suspend device, irqs( ) ; 

mutex, lock ( &dpm list, mix) ; 

// 遍 历 设备 功 耗 管理 列表 的 所 有 设备 

while(! list_empty(&dpm_list) ) | 

// 从 尾部 开始 遍历 ,这 样 保证 按 层次 执行 

struct device * dev =to_device( dpm list. prev) ; 
// 保 证 设备 不 被 释放 


get_device(dev) ; 

















mutex, unlock ( &dpm_list_mtx) ; 





// 使 设备 进入 相应 的 状态 


error = device_suspend_noirq( dev, state) ; 


mutex, lock( &dpm_list_mtx) ; 
if(error) | 
pm. dev, err( dev, state, " late" , error) ; 
put, device( dev) ; 
break ; 
} 
/记录 设备 状态 
dev -> power. status = DPM_OFF_IRQ; 
// 将 正确 操作 的 设备 移入 临时 的 列表 
if( ! list empty( &dev -> power. entry) ) 
list; move( &dev -> power. entry, &list) ; 
/人 /操作 完 计数 减少 
put_device( dev) ; 
} 
// 将 正常 进入 suspend 的 设备 合并 进 设备 功 耗 管理 列表 
list_splice_tail( &list, &dpm_list) ; 











mutex, unlock ( &dpm_list_mtx) ; 
// 如 果 有 错误 ,说 明 进 不 了 待机 状态 , 则 需要 恢复 系统 以 便 正常 执行 


if( error) 











dpm. resume, noirq( resume, event( state) ) ; 
else 
dpm. show. time( starttime, state, "late" ) ; 


return error; 


| 





从 代码 中 可 见 ， 是 想 让 所 有 的 设备 都 进入 待机 状态 ， 下 面 来 看 看 通过 device_suspend_ 
noir 实现 ， 设 备 模型 对 具体 的 设备 进入 相应 待机 状态 的 操作 ; 
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static int device_suspend_noirq( struct device * dev, pm, message. t state) 


| 


int error =0; 


// 检 查 是 否 是 抽象 功能 类 型 设备 ,如 果 是 调用 相关 接口 
if( dev -> class && dev ->class -> pm) | 
pm, dev. dbg( dev, state, "LATE class " ) ; 
error = pm, noirq op( dev, dev —> class -> pm, state) ; 
if( error) 


goto End; 

















// 检 查 具体 的 设备 类 型 (会 依据 class 和 bus 有 不 同情 况 ) ,并 进行 相关 操作 
if( dev -> type && dev -> type -> pm) | 
pm_dev_dbg( dev, state, "LATE type " ) ; 


error = pm, noirq op( dev, dev -» type -> pm, state) ; 








if( error) 


goto End; 





// 检 查 是 否 是 挂 在 总 线 bus 的 设备 ,如 果 是 进行 相关 操作 
if( dev -> bus && dev -> bus -> pm) | 
pm, dev. dbg( dev, state, "LATE ") ; 





error = pm. noirq- op( dev, dev -> bus -> pm, state) ; 


End; 


return error; 











从 具体 实现 中 可 见 ， 其 操作 逻辑 是 按照 之 前 设备 模型 介绍 ， 依 据 设 备 具体 的 情况 进行 
的 。 对 具体 设备 的 电源 管理 实现 ， 将 在 设备 驱动 中 进行 详细 分 析 。SoC 内 部 的 接口 设备 通常 
都 是 platform_device， 所 以 会 执行 bus 的 pm HVE, 具体 如 下 : 




















static const struct dev_pm_ops platform_dev_pm_ops = | 
. prepare = platform. pm, prepare, 
. complete = platform. pm. complete , 
. suspend = platform. pm, suspend, 
. resume = platform pm. resume, 
. freeze = platform, pm. freeze, 
. thaw = platform. pm. thaw, 


. poweroff = platform, pm. poweroff , 
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. restore = platform, pm. restore, 

. suspend. noirq = platform. pm, suspend, noirq,, 

. resume, noirq = platform. pm, resume, noirq, 

. freeze. noirq = platform. pm, freeze, noirq, 

. thaw_noirg = platform. pm. thaw. noirq,, 

. poweroff noirq = platform. pm, poweroff noirq , 

. restore, noirq = platform, pm. restore noirq, 

. runtime, suspend = platform, pm, runtime, suspend, 
. runtime, resume = platform, pm. runtime resume, 


. runtime, idle = platform. pm runtime, idle, 


ys 
而 在 suspend TE ZA T platform. pm, suspend, noirq, ， 细 节 如 下 : 


int weak platform, pm. suspend, noirq( struct device * dev) 


struct device, driver * drv 2 dev —> driver; 


int ret 20; 


if(! drv) 


return 0; 


if( drv -> pm) | 
if( drv -> pm -> suspend. noirq) 


ret = drv —> pm —> suspend. noirq( dev) ; 


return ret ; 


从 中 可 见 ， 具 体 的 是 调用 相应 的 platform. driver 接口 函数 ， 这 样 转 换 好 处 是 使 得 platform 
_device 只 维护 资源 ， 而 driver 则 是 可 以 复 用 的 操作 接口 。 
再 来 看 看 使 整个 系统 进入 待机 的 接口 : 


static int suspend_enter( suspend, state, t state) 


| 


int error; 

















上 /系统 级 的 suspend 接口 通常 由 具体 的 芯片 设置 相关 接口 


if(suspend_ops -> prepare) | 

















error = suspend. ops -> prepare( ) ; 


if( error) 
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goto Platform, finish; 








// 对 所 有 的 普通 设备 进行 suspend 操作 

error = dpm, suspend, noirq( PMSG_SUSPEND) ; 

if(error) | 
printk( KERN, ERR "PM: Some devices failed to power down n" ) ; 
goto Platform, finish ; 








// 继 续 系统 级 的 操作 

if( suspend_ops -> prepare late) | 
error = suspend, ops -> prepare, late( ) ; 
if( error) 


goto Platform, wake; 


if( suspend test( TEST PLATFORM ) ) 


goto Platform, wake; 


// HARA SS AE EEKE suspend 
error = disable nonboot, cpus( ) ; 
if( error || suspend, test( TEST. CPUS) ) 


goto Enable cpus; 


// 体 系 结构 上 可 以 关中 断 
arch_suspend_disable_irqs( ) ; 
BUG. ON(! irqs disabled( ) ) ; 


//sysdev 进行 suspend 操作 
error = sysdev_suspend( PMSG, SUSPEND) ; 
if(! eror) | 
if( ! suspend. test( TEST CORE) && pm. check, wakeup. events( ) ) | 
// 这 里 整个 系统 进入 相应 的 低 功 耗 状态 ,整个 系统 待机 只 
A/ 响应 唤醒 事件 


error = suspend_ops —> enter(state) ; 





events_check_enabled = false; 


| 
// 这 里 系统 已 经 唤醒 , 先 要 恢复 sysdev 


sysdev_resume( ) ; 
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A 
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接口 ， 


// 恢 复 流程 
arch, suspend, enable, irqs( ) ; 


BUG, ON( irqs. disabled( ) ) ; 


Enable. cpus : 


enable nonboot, epus( ) ; 


Platform. wake: 
if( suspend ops -> wake) 


suspend ops —> wake( ) ; 
dpm, resume, noirq( PMSG_RESUME) ; 
Platform. finish; 
if( suspend. ops —> finish) 


suspend ops —> finish( ) ; 


return error; 


| 





以 上 分 析 主 要 是 进入 待机 状态 最 后 阶段 的 操作 流程 ， 而 要 使 得 设备 和 系统 进入 待机 状 














只 提供 一 个 操作 接口 其 实现 的 复杂 度 就 太 高 了 ， 另 外 由 于 设备 层次 以 及 设备 操作 的 复杂 
性 ， 在 进入 待机 状态 之 前 需要 进行 必要 的 保护 ， 所 以 电源 管理 操作 就 应 该 提供 不 同 阶段 的 操 
作 接 口 ， 正 如 在 dev. pm. ops 中 所 见 的 各 种 函数 接口 。 具 体 的 suspend 操作 则 分 为 suspend 
prepare, suspend, suspend noirq 等 儿 个 不 同 的 阶段 ， 并 在 dev_pm_ops 定义 了 相应 的 接口 。 
为 了 遍历 所 有 的 设备 并 执行 相应 的 操作 ，dpm (derice power management) 也 提供 了 相应 的 























分 别 是 dpm, prepare, dpm, suspend 和 dpm_suspend_noirq。 这 样 一 来 所 有 的 设备 就 可 





以 通过 分 阶段 的 操作 完成 必要 的 保护 操作 后 进入 待机 状态 ， 恢 复 过 程 操 作 则 是 待机 操作 的 逆 


从 分 析 可 知 ， 整 个 系统 的 待机 操作 是 从 外 围 设 备 开 始 ， 最 后 到 和 系统 电源 管理 最 紧密 的 


系统 设备 ， 所 以 从 电源 管理 的 角度 设备 也 是 

















分 








层 的 ， 








外 围 设备 就 是 设备 模型 中 的 device， 而 














系统 设备 是 sysdev (如 CPU 、memory 、 核 心 时 钟 源 、 时 间 管 理 部 分 等 都 是 通过 sysdev_regis- 
ter 注册 的 ， 这 与 最 小 系统 所 见 设 备 抽 象 后 的 实体 基本 一 致 ) 。 另 外 内 核 也 为 芯片 提供 了 基本 
的 suspend. ops 待机 操作 接口 来 进行 芯片 级 别 的 特殊 操作 。 








4. runtime pm 和 device wake 





下 面 看 看 设备 的 runtime pm 是 如 何 实现 的 。 每 





runtime, init 来 完成 ， 具 体 分 析 如 下 : 


void pm. runtime, init(struct device * dev) 


| 


// 初 始 化 设备 相关 的 runtime pm 信息 











个 设备 的 runtime pm 初始 化 工作 由 pm_ 
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dev -> power. runtime, status = RPM_SUSPENDED; 


dev —> power. idle notification = false; 


dev -> power. disable depth 21; 


atomic, set( &dev -> power. usage count, 0) ; 


dev -> power. runtime, error 20; 


atomic, set( &dev -> power. child count, 0) ; 
pm. suspend, ignore children( dev, false) ; 


dev -> power. runtime, auto = true; 


dev -> power. request. pending = false; 

dev -> power. request = RPM. REQ. NONE; 

dev -> power. deferred, resume = false; 

dev -> power. accounting timestamp = jiffies; 

// 记 录 设 备 runtime pm 的 执行 实体 

INIT_WORK( &dev -> power. work, pm, runtime work) ; 





dev -> power. timer expires =0; 
setup. timer( &dev -> power. suspend. timer, pm suspend timer fn, 


(unsigned long) dev) ; 


LIVE AE FF AFI 
init_waitqueue_head( &dev -> power. wait, queue) ; 


| 


从 代码 分 析 中 可 见 ， 主 要 是 进行 相关 属性 的 初始 化 ， 男 外 初始 化 了 用 于 异步 执行 runt- 
ime pm 操作 的 work (pm_init 中 会 初始 化 workqueue pm, wq 来 异步 执行 设备 的 runtime pm 操 
YE) 以 及 相应 的 进行 多 个 上 下 文 同步 的 等 待 队列 。 考 上 外 设备 驱动 是 可 以 在 多 个 上 下 文 以 及 
执行 实体 中 运行 ， 而 驱动 操作 的 设备 物理 上 是 唯一 的 实体 ， 这 就 要 求 对 设备 进行 的 动态 电源 
操作 时 需要 进行 同步 。 

设备 的 runtime pm 操作 的 状态 同步 都 是 通过 dev. pm. info 来 完成 的 ， 其 被 包含 在 device 
中 ， 这 样 在 任何 上 下 文 对 设备 进行 runtime pm 操作 的 时 候 都 可 以 同步 。dev_pm_info 的 细节 
如 下 : 



































struct dev_pm_info | 
/人 /所 有 电源 管理 操作 的 锁 


spinlock_t lock ; 























#ifdef CONFIG. PM, RUNTIME 
LECT BEREBRETE SCA ERE TS EE AY HE NT de 
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struct timer_list suspend, timer; 

/定时 器 到 期 的 时 间 

unsigned long timer_expires ; 

// 异 步 操作 需要 的 work 会 在 pm —_wq 工作 队列 上 执行 ， 

// 在 pm. runtime init 中 初始 化 

struct work_struct work ; 

/等待 事件 ,用 于 当 多 个 上 下 文 对 同一 个 设备 进行 相同 操作 时 进行 系统 同步 


wait_queue_head_t wait_queue; 




















































































































/使 用 计数 

atomic_t usage_count; 

//active 的 子 设备 的 计数 

atomic_t child_count; 

// disable 的 深度 等 于 0 表示 可 以 执行 runtime pm 操作 
unsigned int disable depth:3; 

// 忽 略 子 设备 的 状态 

unsigned int ignore children:1 ; 
/表示 在 进行 idle 操作 

unsigned int idle notification ;1; 

// 表 示 有 suspend 操作 请 求 

unsigned int request_pending:1; 
// 当 suspend 正在 执行 时 ,需要 延迟 resume 操作 ,设置 该 状态 表示 resume 延迟 
unsigned int deferred_resume:1; 
// 表 示 运 行 时 唤醒 能 力 

unsigned int run_wake:1; 

unsigned int runtime_auto:1; 

// 不 执行 runtime pm 设备 层面 的 操作 接口 
unsigned int no. callbacks :1 ; 
/自动 休眠 功能 是 否 开启 

unsigned int use autosuspend:1; 
/是 否 在 定时 器 到 期 时 尝试 进行 自动 休眠 
unsigned int timer_autosuspends :1 ; 
// 需 要 执行 的 runtime pm 的 请 求 

enum rpm_request request ; 

//W runtime pm 的 状态 

enum rpm_status runtime_status ; 
/设备 当前 的 错误 状态 值 , 当 有 错误 时 runtime pm 的 操作 无 法 执行 
int runtime_error ; 
/自动 休眠 的 延迟 时 间 

int autosuspend_delay ; 

人 /以 下 是 记录 一 些 时 间 状 态 

unsigned long last_busy ; 

unsigned long active_jiffies ; 


359 


unsigned long suspended. jiffies ; 
unsigned long accounting timestamp; 
#endif 
E 





可 见 其 中 不 仅 包 含 设备 runtime pm 的 本 身 状 态 信 息 ， 还 包含 不 同 操作 方式 (如 同步 、 
异步 ) 的 状态 。 设 备 的 runtime pm 操作 最 终 是 通过 rpm, xxx 来 执行 的 ，xxx 代表 不 同 的 操作 
请 求 ， 主 要 是 idle, suspend 和 resume。 下 面 以 rpm. suspend 为 例 来 分 析 具 体 的 流程 : 











static int rpm, suspend( struct device * dev, int rpmflags ) 


. releases( &dev -> power. lock) __acquires( &dev -> power. lock ) 


int( * callback) (struct device * ) ; 
struct device * parent = NULL; 


int retval; 
dev_dbg( dev, "96s flags Ox%x\n", __fune__, rpmflags) ; 


repeat; 
// 检 查 是 否 能 执行 suspend 操作 ,主要 是 检查 设备 是 否 有 error 状态 ,操作 是 否 enable, 
// 使 用 计数 , 子 设备 的 状态 (通常 只 有 子 设 备 都 suspend, 父 设备 才能 suspend) 等 


retval = rpm_check_suspend_allowed( dev) ; 











if(retval < 0) 
; / * Conditions are wrong. * / 
/ * Synchronous suspends are not allowed in the RPM, RESUMING state. * / 
// 已 经 在 resume 的 过 程 中 ,并 且 要 求 suspend 操作 马上 执行 则 报错 ,保证 操作 的 同步 
else if( dev -> power. runtime_status == RPM_RESUMING && 
! (rpmflags & RPM_ASYNC) ) 
retval = — EAGAIN; 
// AA retval 为 0 表示 没有 问题 
if( retval) 





goto out; 


/ * If the autosuspend, delay time hasn’ t expired yet, reschedule. * / 
// 进 行 自动 suspend 操作 ,但 是 定时 器 还 没有 到 时 则 进行 必要 的 reschedule 操作 
if( ( rpmflags & RPM, AUTO) 

&& dev -> power. runtime, status | = RPM, SUSPENDING) | 


unsigned long expires = pm. runtime autosuspend. expiration( dev) ; 


if( expires ! 20) | 


/ * Pending requests need to be canceled. */ 
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dev —> power. request = RPM_REQ_NONE; 
if( | (dev -> power. timer expires && time_before_eq( 
dev —> power. timer expires, expires) ) ) | 
// 修 改定 时 顺 
dev —> power. timer_expires = expires ; 
mod_timer( &dev — > power. suspend, timer, expires) ; 
| 
dev —> power. timer_autosuspends = 1 ; 


goto out; 


/ * Other scheduled or pending requests need to be canceled. * / 
// 取 消 定 时 器 并 且 直 接 修改 设备 的 runtime pm 的 请 求 为 aone, 这 样 可 以 
// 在 真正 执行 时 直接 返回 ,相当 于 撤销 了 pending 请 求 . 


pm_runtime_cancel_pending( dev) ; 














// 已 经 在 执行 suspend 操作 中 , 则 要 挂 起 ,等待 suspend 操作 完成 
if( dev -> power. runtime, status == RPM, SUSPENDING) | 
DEFINE. WAIT( wait) ; 


// 如 果 是 异步 或 者 不 等 待 的 方式 执行 ,都 返回 运行 中 的 错误 
// 异 步 操 作 返 回 该 错误 是 由 于 本 映 已 经 在 异步 执行 了 
if( rpmflags &( RPM_ASYNC | RPM_NOWAIT)) | 

retval = — EINPROGRESS; 








goto out ; 


/ * Wait for the other suspend running in parallel with us. */ 
// 等 待 异步 suspend 的 完成 
fort 35) 
prepare_to_wait( &dev -> power. wait queue, &wait, TASK UNINTERRUPTIBLE) ; 
// 如 果 状 态 已 经 不 是 suspending 了 ,表示 已 经 完成 退出 循环 
if( dev —> power. runtime_status | = RPM_SUSPENDING) 
break ; 
// 调 度 之 前 释放 锁 
spin_unlock_irq( &dev -> power. lock) ; 


schedule( ) ; 
// 返 回 获得 锁 
spin lock irq( &dev -> power. lock) ; 
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/结束 等 待 则 需要 重新 执行 该 流程 来 保证 同步 


finish_wait( &dev —» power. wait queue, &wait) ; 


pa 








goto repeat ; 


// 可 以 开始 执行 suspend 操作 了 

// 先 设置 延迟 resume 状态 

dev —> power. deferred_resume = false; 
// 设 置 不 执行 操作 , 则 直接 设置 状态 
if( dev -> power. no_callbacks ) 


goto no callback; /* Assume success. * / 


/ * Carry out an asynchronous or a synchronous suspend. * / 
// 如 果 是 进行 异步 操作 , 则 加 入 到 pm. wq 工作 队列 中 执行 
if( rpmflags & RPM_ASYNC) | 
dev -> power. request = ( rpmflags & RPM, AUTO) ? RPM, REQ AUTOSUSPEND: RPM, REQ SUS- 
PEND; 
if( ! dev -> power. request, pending) | 





dev -> power. request. pending = true; 
queue. work( pm. wq, &dev -> power. work) ; 


| 
// 加 入 队列 就 可 以 退出 


goto out; 
// 设 置 suspending 状态 
__update_runtime_status( dev, RPM_SUSPENDING) ; 


// 根 据 设备 的 runtime pm 的 接口 设置 ,选择 操作 接口 
if( dev -> bus && dev -> bus -> pm && dev —>bus—>pm—>runtime_ suspend) 





callback = dev -> bus -> pm —> runtime suspend; 
else if( dev -> type && dev -> type -> pm && dev -> type -> pm —> runtime, suspend) 
callback = dev —> type -> pm —» runtime, suspend ; 
else if( dev -> class && dev -> class -> pm) 
callback = dev -> class -> pm —> runtime, suspend ; 
else 
callback = NULL; 
// 3A 1 runtime, suspend 操作 
retval = rpm, callback( callback, dev) ; 
if(retval) | 
// 没 有 suspend 成 功 , 则 恢复 active 状态 
__update_runtime_status(dev, RPM_ACTIVE) ; 
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dev -> power. deferred, resume 20; 
// 如 果 是 重新 执行 或 者 busy 错误 则 清除 错误 值 ,否则 取消 pending 的 操作 
if( retval == — EAGAIN || retval == -EBUSY) 


dev -> power. runtime, error 20; 





else 
pm. runtime, cancel, pending( dev) ; 
| else | 
no. callback : 
// XX FEM suspend 操作 成 功 
. update runtime status( dev, RPM, SUSPENDED) ; 


pm, runtime, deactivate, timer( dev) ; 


if( dev -> parent) | 
// 对 于 父 设备 的 active 子 设 备 数目 做 减 操作 


parent = dev —> parent; 





atomic_add_unless( &parent -> power. child count, —1, 0); 


| 
//suspend 操作 完成 则 唤醒 其 他 等 待 的 任务 


wake_up_all(&dev -> power. wait, queue) ; 





// WIS KEIR resume 操作 ,这 时 可 以 执行 了 
if( dev -> power. deferred resume) | 
// 执 行 resume 操作 
rpm_resume(dev, 0) ; 
//suspend 操作 没 成 功 应 该 再 操作 
retval = -上 EACAIN ; 





goto out; 














// 这 里 如 果 有 父 设备 ,在 父 设备 考虑 子 设备 状态 时 ,考虑 进入 idle 
if( parent && | parent -> power. ignore_children) | 
// 操 作 之 前 释放 锁 
spin, unlock, irq( &dev -> power. lock) ; 
// 异 步 执 行 父 设 备 idle 操作 
pm_request_idle( parent) ; 
// 执 行 完 获得 锁 
spin_lock_irq( &dev -> power. lock) ; 








out: 


363 


dev. dbe( dev, "96s returns % d\n", _ func retval) ; 


——9 


return retval ; 


| 


从 分 析 中 可 见 ，runtime pm 的 操作 很 好 地 考虑 了 多 上 下 文 执行 以 及 多 种 操作 方式 的 情 
况 ， 保 证 对 于 设备 操作 的 同步 。 

除 此 之 外 系统 提供 了 一 系列 的 操作 接口 来 帮助 驱动 进行 runtime pm 操作 ， 下 面 是 一 些 接 
口 的 例子 : 











// 执 行 设备 所 在 总 线 或 者 class 应 执行 的 runtime, idle 操作 

int pm_runtime_idle( struct device * dev) ; 

// 执 行 设备 所 在 总 线 或 者 class 应 执行 的 runtime, suspend 操作 

int pm_runtime_suspend( struct device * dev); 

// 5j pm. runtime, suspend( ) 相同 ,会 考虑 自动 休眠 延迟 的 时 间 

int pm_runtime_autosuspend( struct device * dev) ; 

// 执 行 设备 所 在 总 线 或 者 class 应 执行 的 runtime_resume 操作 

int pm_runtime_resume( struct device * dev) ; 

// 提 交 执 行 设备 所 在 总 线 或 者 class 应 执行 的 runtime. idle 操作 ,由 pm. wq work 执行 
int pm_request_idle( struct device * dev) ; 

// 提 交 执 行 设备 所 在 总 线 或 者 class 应 执行 的 runtime, resume 操作 ,由 pm. wq work 执行 
int pm_request_resume( struct device * dev); 

// 递 增设 备 的 使 用 计数 

void pm_runtime_get_noresume( struct device * dev) ; 

// 递 增设 备 的 使 用 计数 j 运行 pm_request_resume 

int pm_runtime_get( struct device * dev) ; 

// 递 增设 备 的 使 用 计数 ,运行 pm_runtime_resume 

int pm, runtime get, sync( struct device * dev) ; 

// 递 减 设备 的 使 用 计数 

void pm_runtime_put_noidle( struct device * dev) ; 

// 设 备 的 使 用 计数 减 1 ,如 果 结 果 是 0, 则 运行 pm. request. idle 

int pm_runtime_put( struct device * dev); 

// 设 备 的 使 用 计数 减 1 ,如 果 结 果 是 0, 则 运行 pm_runtime_idle 

int pm, runtime put, sync( struct device * dev); 

// 设 备 的 使 用 计数 减 1 ,如 果 结 果 是 0, 则 运行 pm. runtime, suspend 


int pm_runtime_put_sync_suspend( struct device * dev) ; 



























































// 使 能 runtime pm 的 辅助 函数 ,允许 执行 设备 所 在 总 线 或 者 class 应 执行 的 接 


void pm_runtime_enable( struct device * dev) ; 
// 防 止 新 的 执行 请 求 , 确 保 设 备 的 所 有 等 待 中 的 操作 已 完成 或 取消 


int pm_runtime_disable( struct device * dev) ; 





E 
ES 
EE 





具体 设备 的 runtime pm 的 操作 接口 定义 如 下 : 
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struct dev_pm_ops | 
int( * runtime suspend) ( struct device * dev); 


int( * runtime, resume) (struct device * dev); 


int( * runtime, idle) ( struct device * dev); 


ls 





5 SLM 的 操作 接口 类 似 都 在 dev_pm_ops 中 进行 定义 ， 会 有 设备 及 各 种 总 线 以 及 class if 
行 实现 ， 实 际 的 操作 也 是 要 按照 层次 执行 。 





下 面 列举 了 一 个 设备 驱动 中 如 何 使 用 runtime pm 的 简单 例子 。 
probe 阶段 时 流程 通常 如 下 : 





pm_runtime_enable 
执行 驱动 自己 的 probe 配置 硬件 


pm_runtime_suspend 








需要 进行 工作 时 操作 流程 如 下 : 


pm_runtime_get 
具体 工作 


pm_runtime_put 


没有 具体 的 工作 时 可 以 直接 通过 pm. runtime, suspend 来 使 得 设备 进入 suspend KAS, AL 
体 的 操作 由 驱动 根据 实际 情况 调用 runtime pm 提供 的 各 种 接口 来 完成 。 

设备 在 电源 管理 方面 除了 suspend 和 resume 的 功能 外 ， 还 有 就 是 能 够 唤醒 系统 的 能 
在 唤醒 系统 的 能 力 方 面 device 中 的 struct dev_pm_info 有 can_wakeup 属性 表示 wakeup 的 能 力 
和 wakeup 属性 表示 唤醒 源 的 信息 等 ， 通 过 这 些 属 性 来 标记 设备 wakup 的 能 力 以 及 状态 。 男 








外 提 舍 





























E f All wakup 相关 的 接口 如 下 : 


extern struct wakeup_source * wakeup_source_create( const char * name) ; 
extern void wakeup. source, destroy ( struct wakeup_source * ws); 

extern void wakeup. source, add( struct wakeup, source * ws); 

extern void wakeup, source, remove( struct wakeup, source * ws); 

extern struct wakeup. source * wakeup. source, register( const char * name) ; 
extern void wakeup. source, unregister( struct wakeup, source * ws); 

extern int device, wakeup. enable( struct device * dev) ; 

extern int device, wakeup. disable( struct device * dev) ; 

extern int device init wakeup(struet device * dev, bool val) ; 

extern int device set wakeup. enable( struct device * dev, bool enable) ; 
extern void __pm_stay_awake( struct wakeup, source * ws); 

extern void pm, stay. awake( struct device * dev) ; 


extern void _ pm relax( struct wakeup, source * ws); 
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extern void pm_relax(struct device * dev) ; 
extern void _ pm, wakeup. event( struct wakeup_source * ws, unsigned int msec) ; 


extern void pm_wakeup_event( struct device * dev, unsigned int msec) ; 


这 里 的 接口 主要 满足 对 设备 在 一 定时 间 内 唤醒 系统 的 相关 需求 ， 具 体 的 wakeup 源 是 定 
时 器 ， 驱 动 可 以 根据 需要 进行 调用 。 男 外 在 设备 suspend 的 时 候 还 可 以 通过 device_may_ 
wakeup 来 检查 设备 是 否 可 能 唤醒 系统 而 进行 必要 的 唤醒 设置 (主要 通过 对 set_irq_wake 的 封 
装 接口 set_irq_wake 来 实现 ) 。 

至 此 对 主要 的 电源 管理 功能 都 进行 了 介绍 和 分 析 。 

















5.6 内 核 提 供 的 同步 操作 、 异 步 事件 与 单独 执行 实体 的 服务 


5.6.1 同步 操作 服务 


1. 等 待 队 列 wait queue 

用 户 对 数据 的 访问 有 同步 和 异步 两 种 方式 ， 用 户 同步 的 访问 在 内 核 中 通常 并 不 是 直接 执 
行 的 ， 而 是 需要 在 男 外 的 上 下 文 执 行 。 这 就 需要 内 核 针 对 这 种 同步 操作 提供 相应 的 服务 ， 通 
常 的 方式 就 是 用 户 的 上 下 文 进 行 等 待 ， 等 到 操作 完毕 再 进行 唤醒 ， 这 种 等 竺 和 唤醒 都 需要 在 
驱动 内 部 执行 ， 只 是 驱动 在 不 同 的 上 下 文 执行 里 了 。 内 核 针 对 这 种 情况 提供 的 同步 操作 服务 
就 是 等 待 队 列 wait_queue。 

等 待 队列 框图 如 图 5-35 所 示 。 





































































































task_struct task_struct 
> »- 
wait queue t wait queue t wait queue t 
flags flags flags 
task task task 
wait queue head t 
func func func 
lock 
task list task list task list task list 
- - E ) _ = 
next next next next 
rev rev rev rev 
p! p » p » p 






































图 5-35 ”等 待 队列 框图 
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从 图 5-35 FLL, wait queue head t 为 等 待 队 列 的 头 。 如 果 需 要 等 待 相应 的 task 则 会 通 
过 wait. queue. t 加 入 到 等 竺 队列 中 。 相 应 的 操作 围绕 着 wait. queue. head. t, wait. queue. t 和 
task 来 完成 。 下 面 介 绍 主要 的 接口 。 

定义 和 初始 化 等 待 队列 头 : 











wait_queue_head_t my_queue; 
init_waitqueue_head( &my_queue) ; 


DECLARE WAIT QUEUE HEAD( my. queue) ; 宏 定义 实现 
定义 并 初始 化 等 待 队 列 项 . 
DECLARE_WAITQUEUE(name, tsk) ; 


添加 / 移 除 等 待 队列 项 . 


void fastcall add_wait_queue( wait, queue head t * q, wait queue t * wait); 


void fastcall remove, wait, queue( wait, queue, head t * q, wait, queue t * wait) ; 
yan 
等 待 事件 : 


wait, event( wq, condition) ;不 可 中 断 的 等 待 
wait, event, interruptible( wq, condition) ;可 中 断 的 等 待 

wait_event_timeout(wq, condition, timeout) ; 带 超时 返回 的 等 待 
wait_event_interruptible_timeout(wq, condition, timeout) ;可 中 断 并 超时 返回 的 等 待 














唤醒 队列 : 


wake_up(wait_queue_head_t*q) ; IMIE q 上 所 有 等 待 的 进程 
wake_up_interruptible(wait_queue_head_t *dq) ;只 唤醒 q 上 执行 可 中 断 休眠 的 进程 











下 面 是 驱动 中 将 任务 加 入 等 待 队列 的 基本 流程 : 


/定义 等 待 队列 
DECLARE_WAITQUEUE( wait, current) ; 





/ LEA RE BAI EA TEE Fr SG, PU SE Te e E SE BP EM 
add, wait, queue( &dev -> wait, head, &wait) ; 











// 设 置 进程 状态 为 睡眠 
. set, current, state( TASK_INTERRUPTIBLE) ; 


























// 调 度 其 他 进程 执行 
schedule( ) ; 
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其 中 会 包括 必要 的 数据 保护 操作 以 及 设备 状态 的 检查 。 这 样 希望 同步 操作 的 任务 就 可 以 
等 待 相关 操作 的 完成 了 。 在 驱动 操作 完成 的 回调 中 ， 通 过 等 待 队列 的 唤醒 队列 的 接口 ， 唤 醒 
相关 的 上 下 文 继续 执行 ， 使 得 schedule 返回 ， 继 续 进 行 后 续 的 操作 ， 这 样 就 完成 同步 服 
ST. 

2. 完成 量 completion 

除了 针对 应 用 task 的 同步 操作 服务 外 ， 内 核 经 常会 有 任务 需要 同步 ， 比 如 初始 化 时 某 个 任 
务 需要 等 待 男 外 任务 的 一 个 操作 完成 等 。 这 只 是 两 个 任务 之 间 简 单 的 同步 ， 使 用 等 待 队 列 显得 
大 材 小 用 了 ， 因 此 内 核 提 供 完 成 量 completion 来 进行 这 种 类 型 的 操作 。 相 关 接 口 如 下 : 


























=> 

















init_completion( struct completion * ) ; 初始 化 指定 的 动态 创建 的 完成 变量 
wait_for_completion( struct completion * ) ; 等 待 指定 的 完成 变量 接收 信和 号 


complete(struct completion * ) ; 发 信号 唤醒 任何 等 待 任务 








从 接口 可 见 ， 完 成 量 十 分 简洁 ， 非 常 适合 两 个 任务 之 间 的 同步 服务 。 
5.6.2 异步 事件 


1. 异步 IO AIO 

除了 同步 数据 读 写 之 外 ， 内 核 还 提供 了 异步 读 写 功能 ， 对 于 VES 文件 相关 的 接口 是 aio 
read 和 aio. write 等 。AIO 帮助 用 户 程 序 提高 性 能 以 提高 整体 CPU 和 I0 设备 的 利用 率 ， 特 
别 是 高 IO 负载 的 效率 。 在 服务 型 应 用 中 比较 广泛 的 应 用 ， 比 如 各 种 代理 服务 器 ， 数 据 库 ， 
流 服务 器 等 等 。 

AIO 可 以 一 次 性 发 出 大 量 的 read/write 请 求 ， 请 求 完 成 后 统一 返回 。 这 样 在 用 户 程序 的 
角度 减少 了 因 同 步 操 作 产生 的 负载 ， 相 当 于 应 用 层 的 数据 批 处 理 功能 。 

Linux AKA AIO 提供 了 系统 调用 来 完成 异步 10 的 功能 ， 相 关 调 用 如 下 : 

e io setup( ) ; 为 当前 进程 建立 异步 IO 上 下 文 。 

e io_submit( ) ; 提交 一 个 或 者 多 个 异步 10 操作 。 

* io getevents( ) ; 获得 完成 的 异步 10. 的 状态 。 

e io_cancel( ) ; 取消 某 个 IO 操作 。 

e io_destroy( ) ; 销毁 异步 IO EFX, 

下 面 提供 一 个 简单 的 例子 ,便于 了 解 如 何 使 用 异步 10。 具 体 如 下 : 





























#include < errno. h > 
#include < stdio. h > 
#include < fentl. h > 
#include < unistd. h > 
#include < string. h > 
#include < stdlib. h > 
#include < sys/stat. h > 
#include < sys/types. h > 
#include < libaio. h > 
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int main( ) 
io_context_t ctx; 
struct iocb * iocb; 


struct io. event events[ 10 ] ; 


char * buf; 
int fd; 
unsigned nr events = 10; 


struct timespec timeout = |1, 100] ; 


// 初 始 化 异步 IJO0 上 下 文 管理 结构 
memset( &etx, 0, sizeof( ctx) ) ; 
// 创 建 异 步 10 上 下 文 


io_setup(nr_events, &ctx) ; 























// 目 前 要 指定 O_DIRECT ,这样 io_submit 操作 才能 使 用 异步 IO 
int fd = open(". /test. txt" , O_DIRECT | O_WRONLY, S IRWXU | S_IRWXG | S_IROTH) ; 








// 分 配 的 空间 要 求 对 齐 

posix_memalign( ( void * * ) &buf, sysconf(_SC_PAGESIZE) , sysconf(_SC_PAGESIZE) ) ; 
// 在 相应 空间 写 入 内容 

strepy( buf, "test" ) ; 


// 分 配 异步 10 操作 结构 
iocb = (struct iocb * ) malloc( sizeof( struct iocb) ) ; 


memset( iocb, 0, sizeof( struct iocb) ) ; 


// 设 定 异步 10 操作 








iocb[ 0 ]. data = buf; 

iocb[ 0]. aio lio opeode =IO_CMD_PWRITE; 
iocb[ 0 ]. aio, reqprio =0; 

iocb[ 0 ]. aio_fildes =fd; 

iocb[ 0]. u. c. buf = buf; 

// 这 个 值 必须 按 512 B 对 齐 

iocb[ 0 ]. u. c. nbytes = page. size; 
iocb[ 0 ]. u. c. offset =0; 




















// 提 交 蜡 步 YO 操作 ,这 里 是 异步 写 磁盘 
io_submit(ctx, 1, &iocbpp) ; 
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// 检 查 写 磁盘 情况 ,类 似 于 epoll wait 或 select 


io_getevents(ctx, 1, 10, events, &timeout) ; 


VES SNE 
close( fd) ; 
// 销 毁 异步 10 上 下 文 


io. destroy ( ctx) ; 





return 0; 


| 


从 应 用 代码 可 见 ， 异 步 I0 更 适合 直接 对 块 设备 进行 操作 。 通 过 进行 一 次 大 量 的 异步 读 
写 来 减少 同步 开销 ， 从 而 提高 效率 ， 这 种 场景 更 适合 使 用 块 设备 的 服务 ， 如 数据 库 、 流 服 
务 等 。 

异步 I0 的 内 核实 现 框 架 如 图 5-36 所 示 。 


AIO Infrastructure 





































































































































































next Ring Buffer next 
„£ J 
ctx_lock ctx_lock 
tail head 
«-——— X 
aio complete() lo getevents() 
active reqs » active reqs 
worker clie » ki list » ki list ki list zea 
thread ki_ctx ki_ctx ki_ctx 
ki_key ki_key ki_key 
run list ki_run_list ki_run_list ki_run_list run list 
app g ; P p B 
threads ki pos ki pos ki pos 
ki buf ki buf ki, buf 
= : - retry_func() 
ki_left ki_left ki_left { 
< < wait ki_retry ki_retry kiretry > ees wait 
ki_cancel ki_cancel } 
ki_wait ki_wait ki_wait 
page wait 
queue 
wait_func() 
} 





5-36 ”异步 I0 内 核实 现 框架 








从 图 5-36 可 见 ， 每 个 异步 I0 的 上 下 文 都 包含 真正 执行 10 操作 的 实体 work (在 worker 
线程 上 执行 ) M 10 操作 的 完成 情况 通过 ring buffer 实现 内 核 与 用 户 之 间 交 互 。 
相应 的 执行 实体 初始 化 是 在 分 配 LO 上 下 文 的 函数 ioctx_alloc 来 进行 的 ， 具体 如 下 : 
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INIT. DELAYED. WORK( &etx -> wq, aio. kick. handler) ; 


在 需要 执行 IO 操作 时 ， 会 调度 work 执行 aio_kick_handler。 其 中 ， 调 用 aio_run_iocb 对 
每 个 kiocb 进行 操作 ， 调 用 ki. rey 执行 具体 的 操作 。 而 kiocb 在 创建 时 会 根据 具体 的 TO 操 
作 通 过 aio_setup_iocb 分 配合 适 的 操作 接口 给 ki_retry。 读 写 操作 通常 设置 为 aio_rw_vect_re- 
try， 下 面 来 分 析 一 下 aio_rw_vect_retry 的 实现 : 











static ssize_t aio_rw_vect_retry(struct kiocb * iocb) 
| 
struct file * file = iocb —» ki_filp; 
struct address space * mapping = file -> f mapping; 
struct inode * inode = mapping —> host; 
ssize t( * rw op) (struct kiocb * , const struct iovec * , 
unsigned long, loff_t) ; 
ssize t ret =0; 


unsigned short opcode; 





// 根 据 操作 ,从 文件 操作 接口 中 获得 正确 的 操作 函数 

if( (iocb ->ki opeode == IOCB_CMD_PREADV) || 
(iocb -> ki_opeode ==IOCB_CMD_PREAD) ) | 
rw. op = file ->f op -> aio. read ; 


opcode = IOCB. CMD. PREADV ; 





| else | 
rw. op = file -> f op -> aio. write; 


opcode = IOCB. CMD. PWRITEV ; 


/ * This matches the pread( ) /pwrite( ) logic ** / 
if(iocb -> ki pos < 0) 
return. — EINVAL; 


/遍历 对 请 求 的 所 有 IO 进行 操作 
do | 





// 执 行文 件 的 异步 接口 

ret =rw_op(iocb, &iocb -> ki, iovec[ iocb -> ki, cur. seg], 
iocb —» ki nr segs — iocb —» ki. cur. seg, 
iocb —» ki. pos) ; 

if( ret » 0) 


aio. advance, iovec( iocb, ret); 


/ * retry all partial writes. retry partial reads as long as its a 


* regular file. */ 
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| while( ret >0 && iocb —>ki_left >0 && 
(opcode == IOCB_CMD_PWRITEYV || 
(! S_ISFIFO(inode -»i mode) && ! S ISSOCK( inode -» i. mode) ) ) ) ; 


/ * This means we must have transferred all that we could */ 
/ * No need to retry anymore * / 
// 一 切 正常 则 返回 操作 数目 
if( (ret 220) || (iocb -> ki_left ==0) ) 

ret = iocb —> ki, nbytes — iocb -> ki left; 





/ * If we managed to write some out we return that, rather than 
* the eventual error. */ 
if( opcode == IOCB_CMD_PWRITEV 
&& ret < 0 && ret | = - EIOCBQUEUED && ret | = - EIOCBRETRY 
&& iocb -> ki. nbytes -iocb -> ki. left) 
ret = iocb —» ki, nbytes — iocb -> ki left; 


return ret; 


| 


从 代码 中 可 见 ， 其 主要 是 通过 文件 的 异步 接口 来 执行 所 有 的 异步 请 求 ， 而 相应 的 异步 接 
口 通常 由 具体 的 文件 系统 提供 ， 如 ext2 文件 系统 的 ext2_file_operations 中 就 包含 各 种 异步 操 
作 接 口 。 具 体 的 文件 系统 后 续 的 操作 在 块 设备 层 已 经 进行 了 介绍 。 可 见 Linux 内 核 已 经 为 异 
步 10 提供 了 完整 的 上 层 框 架 ， 对 于 具体 的 操作 则 是 通过 VES 中 的 异步 接口 完成 的 。 这 样 将 
具体 的 文件 TO 操作 转移 到 异步 I0 框架 中 执行 ， 用 户 层 则 不 需要 同步 等 待 事件 的 完成 ， 从 而 
在 需要 进行 大 量 操作 时 整体 的 性 能 要 高 很 多 。 

2. 通知 链 notifier 

Linux 内 核 的 各 个 子 系统 功能 上 都 是 相互 独立 的 ， 但 是 各 个 子 系统 之 间 同 样 需要 交互 ， 
例如 某 个 子 系统 可 能 对 其 他 子 系统 产生 的 事件 感 兴趣 。 如 何 让 各 个 子 系统 之 间 能 够 方便 地 通 
知 相关 的 事件 并 进行 合适 的 操作 ， 这 属于 横 切 的 异步 功能 。Linux 内 核 为 了 满足 该 需求 设计 
了 通知 链 的 机 制 。 通 知 链 是 为 内 核 各 个 模块 异步 交互 服务 的 ， 只 能 够 在 内 核 的 子 系统 之 间 使 
用 ， 而 不 能 够 用 于 内 核 与 用 户 空 间 之 间 进 行事 件 的 交互 。 
通知 链表 是 一 个 函数 链表 ， 链 表 上 的 每 一 个 节点 都 注册 了 一 个 函数 。 当 某 个 事件 发 生 
时 ,链表 上 所 有 节点 对 应 的 函数 就 会 被 执行 。 所 以 通知 链表 有 一 个 通知 方 与 很 多 接收 方 。 在 
通知 这 个 事件 时 所 运行 的 函数 由 接收 方 决 定 ， 就 是 接收 事件 方 注册 了 回调 函数 ， 在 发 生 某 个 
事件 时 回调 函数 就 得 到 执行 。 系 统 运行 时 通知 链 的 状态 如 图 5-37 所 示 。 

从 图 5-37 可 见 ， 其 中 包含 两 个 主要 的 实体 ， 一 个 是 head， 男 一 个 是 block, head 是 由 
事件 通知 者 提供 ， 而 block 是 由 事件 接收 者 向 事件 通知 者 注册 的 。 

Linux 内 核 提 供与 通知 链 相 关 的 结构 体 如 下 : 
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block‘ block3 NULL 


图 5-37 通知 链 运行 时 状态 图 


struct notifier block | 
int( * notifier call) (struct notifier block * , unsigned long, void * ) ; 
struct notifier block rcu * next; 
int priority ; 


E 


struct atomic_notifier_head | 
spinlock t lock ; 


struct notifier block __rcu * head; 


l; 


struct blocking_notifier_head | 
struct rw_semaphore rwsem; 


struct notifier_block __rcu * head; 


E 


struct raw, notifier head | 


struct notifier block __rcu * head; 


bs 


struct srcu_notifier_head | 
struct mutex mutex; 
struct srcu_struct srcu; 


struct notifier block __rcu * head; 


bs 


从 中 可 见 ， 有 一 个 与 block 相关 的 结构 notifier_block ， 有 四 个 head 相关 的 结构 xxxx_noti- 
fier_head。 为 什么 有 四 种 事件 通知 者 呢 ? 这 是 由 于 内 核 事 件 本 身 可 能 在 不 同 的 上 下 文中 发 
生 ， 通 常 在 事件 发 生 时 就 要 进行 事件 通知 ， 而 对 通知 的 回调 操作 会 有 限制 ，Linux 内 核 就 直 
接 将 这 些 限制 通过 通知 者 的 结构 实现 ， 这 样 依据 不 同 的 情况 产生 了 四 种 head, 2835 4H P : 

* atomic_notifier_head 通知 链 block 的 回调 函数 ( 当 事 件 发 生 时 要 执行 的 函数 ) 只 能 在 
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中 断 上 下 文中 运行 ， 不 允许 阻塞 。 

* blocking notifier head 通知 链 元 素 的 回调 函数 在 进程 上 下 文中 运行 人 允许 阻塞 。 

* raw_notifier_head 对 通知 链 元 素 的 回调 函数 没有 任何 限制 所 有 锁 和 保护 机 制 都 由 调 
用 者 维护 。 

* srcu_notifier_head 可 阻塞 通知 链 的 变种 ， 使 用 SRCU (sleepable read - copy update) 来 
替代 rw - semaphores 进行 通知 链 的 保护 。 

根据 不 同类 型 的 通知 链 ， 内 核 提 供 了 不 同 的 注册 函数 ， 具 体 如 下 : 




















extern int atomic_notifier_chain_register( struct atomic_notifier_head * nh, 
struct notifier block * nb); 

extern int blocking notifier chain, register( struct blocking notifier head * nh, 
struct notifier block * nb); 

extern int raw, notifier chain register( struct raw, notifier head * nh, 
struct notifier block * nb) ; 

extern int srcu, notifier chain, register( struct srcu, notifier head * nh, 


struct notifier block * nb); 








相应 的 内 核 还 提供 了 事件 发 布 函数 ， 由 通知 者 调用 来 进行 事件 发 布 并 对 通知 链 中 注册 的 
接收 者 操作 进行 调用 ， 细 节 如 下 : 








extern int atomic_notifier_call_chain( struct atomic_notifier_head * nh, 
unsigned long val, void * v); 


extern int — atomic, notifier call chain(struct atomic_notifier_head * nh, 





unsigned long val, void * v, int nr to. call, int * nr calls) ; 
extern int blocking notifier call chain( struct blocking notifier head * nh, 
unsigned long val, void * v); 


extern int — blocking notifier call chain( struct blocking notifier head * nh, 





unsigned long val, void ** v, int nr to call, int * nr calls) ; 
extern int raw, notifier call chain( struct raw, notifier head * nh, 
unsigned long val, void ** v); 


extern int _ raw, notifier call chain( struct raw, notifier head * nh, 





unsigned long val, void * v, int nr to. call, int * nr calls) ; 
extern int srcu, notifier call. chain( struct srcu, notifier head * nh, 
unsigned long val, void * v); 


extern int — srcu, notifier call, chain( struct sreu, notifier head * nh, 





unsigned long val, void * v, int nr to. call, int * nr calls) ; 





Linux 内 核 还 提供 了 head 的 定义 宏 ， 细 节 如 下 : 


#define ATOMIC_NOTIFIER_HEAD( name) \ 
struct atomic_notifier_head name = \ 
ATOMIC_NOTIFIER_INIT( name) 
#define BLOCKING. NOTIFTER, HEAD( name) V 
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struct blocking_notifier_head name = \ 
BLOCKING_NOTIFIER_INIT( name) 
#define RAW_NOTIFIER_HEAD( name) \ 
struct raw_notifier_head name = \ 


RAW_NOTIFIER_INIT( name) 





具体 的 事件 是 由 通知 者 模块 进行 定义 的 ， 相 应 的 接收 者 也 需要 清楚 具体 的 事件 ， 并 在 回 
调 中 根据 事件 进行 正确 的 操作 。 对 接收 者 来 说 ， 重 要 的 是 将 block 注册 加 入 正确 的 通知 链 
中 ， 要 做 到 这 一 点 需要 知道 具体 的 head。 这 相当 于 要 知道 模块 的 细节 ， 提 高 了 模块 间 的 耦 
合 度 ， 更 好 的 方法 是 事件 的 发 布 者 所 在 的 模块 提供 一 个 接口 函数 用 于 注册 block 信息 ， 这 样 
接收 者 就 不 需要 关心 事件 发 布 模块 的 细节 ， 降 低 了 通知 链 间 各 模块 的 耦合 度 。Linux 内 核 也 
是 通过 该 方法 实现 的 。 

内 核 运行 过 程 中 会 有 各 种 各 样 的 异步 事件 发 生 ， 而 通过 通知 链 技术 使 得 系统 中 各 个 模块 
的 交互 变 得 简洁 ， 事 件 的 发 布 者 只 要 将 事件 发 布 即 可 ， 可 以 不 用 关心 接收 者 的 细节 ， 接 收 者 
则 只 关心 事件 而 不 用 关心 发 布 者 的 实现 ， 这 样 的 设计 简单 、 清 晰 并 且 耦 合 度 也 是 很 低 的 。 


5.6.3 ”单独 执行 实体 服务 


1. 工作 队列 work queue 

Linux 内 核 中 很 多 模块 会 有 一 些 延 时 操作 的 需求 ， 由 于 内 核 中 各 种 上 下 文 能 进行 的 操作 
不 同 ， 所 以 延 时 操作 最 简单 的 办 法 就 是 能 够 在 单独 的 进程 上 下 文中 执行 ， 这 样 可 以 进行 各 种 
复杂 的 操作 而 相对 限制 最 少 。 如 果 让 内 核 中 各 个 模块 的 延 时 操作 都 要 创建 进程 ， 则 系统 运行 
时 会 占用 大 量 的 资源 ， 同 时 也 增加 了 系统 调度 的 开销 。 如 何 做 才 是 最 好 的 呢 ? 对 延 时 操作 来 
说 其 抽象 的 概念 是 操作 ， 而 操作 的 软件 化 抽象 就 是 函数 。 如 果 系 统 可 以 根据 当前 系统 的 运行 
情况 动态 地 创建 执行 实体 ， 而 当 模块 有 延 时 操作 需要 时 直接 将 这 些 操 作 本 身 加 入 到 系统 提供 
的 进程 上 执行 ， 这 样 既 满足 了 各 个 模块 的 功能 需求 ， 又 可 以 使 系统 资源 占用 最 少 ， 兼 顾 了 功 

性 能 两 个 方面 。Linux 内 核 提 供 的 工作 队列 就 实现 了 该 功能 ， 对 各 个 模块 来 说 ， 其 需要 
系统 进行 的 延 时 操作 就 是 一 个 一 个 的 “工作 ”。 

Linux 内 核 运 行 时 工作 队列 状态 如 图 5-38 所 示 。 

从 图 5-38 可 见 ，Linux 内 核 根据 需要 在 不 同 的 人 处理 器 上 创建 执行 实体 线程 ， 来 执行 具 
体 的 work， 这 些 work 都 是 动态 添加 的 。 整 个 work queue 的 管理 实体 是 workqueue_struct， 其 
中 可 以 包含 多 个 线程 ， 分 别 执行 相应 的 延 时 工作 。 

Linux 内 核 为 系统 提供 了 一 些 默认 的 work queue, HARAN F : 


















































extern struct workqueue_struct * system_wq; 
extern struct workqueue_struct * system. long wq; 
extern struct workqueue. struct * system. nrt. wq; 


extern struct workqueue, struct * system, unbound, wq; 


这 些 work queue 会 由 不 同 的 接口 向 其 中 添加 工作 ， 每 个 工作 队列 的 执行 特点 也 是 不 同 
HJ, system wg 会 有 多 个 任务 执行 ， 但 是 希望 每 个 work 不 要 消耗 太 长 时 间 ; system. long. wq 
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类 似 于 system_wq， 但 是 允许 长 时 间 的 work HÍT; system, nrt. wq 确保 work ZEA, 并且 
不 会 在 多 个 处 理 器 上 执行 ;system_unbound_wq 则 不 会 将 work 固定 在 某 个 处 理 器 上 执行 并 
将 尽快 尽力 执行 。 通 常 默认 使 用 的 是 system_wq， 也 可 以 根据 需要 通过 queue_work 将 work 加 


和 人 到 具体 的 work queue 上 来 执行 。 








create_workqueue 


list 

















CPUO 
wq cwq 
cpu wq lock 
workqueues list worklist 
C “name” more_work 


由 于 系统 已 经 提供 了 各 种 类 型 的 工作 队列 ， 对 模块 开发 来 说 ， 延 时 操作 最 重要 的 就 是 





singlethread 





current_work 








freezeable 





wq 














thread 








worklist 
more work 





current work 





wq 








thread 
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work work work 
data list data data 
entry d entry que entry 
func func func 
wait 


autoremove wake function 
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K 5-38 工作 队列 运行 状态 


work 了， 系统 对 work 管理 的 结构 是 work_struct， 细 节 如 下 : 


struct work, struct | 


atomic, long t data; 


struct list head entry; 


work, fune, t func; 


ls 


结构 很 简单 ， 其 中 对 模块 最 习 


typedef void( * work func, t) (struct work, struct. * work) ; 











work work work 
data list data data 
entry KK‘ entry entry 
func func func 
wait 


autoremove_wake_function 


要 的 是 操作 接口 work func t, BARE XT: 


从 中 可 见 传 入 的 参数 并 不 是 模块 相关 的 ， 那 么 模块 如 何 获 得 其 管理 实体 的 信息 呢 ? 方法 
就 是 将 work_struct 做 成 静态 的 形式 并 般 入 模块 管理 实体 中 ， 这 样 通过 container. of 就 可 以 获 


得 相关 的 管理 实体 。 为 此 工作 队列 框架 提供 了 相应 的 初始 化 宏 : 
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#define INIT WORK(. work, _func) \ 
do | V 
. INIT WORK( (. work) , (. func) , 0) ;\ 
| while(0) 








工作 队列 框架 还 提供 了 一 系列 接口 函数 方便 各 个 模块 使 用 ， 接 口 说 明 如 下 : 
* create workqueue: 用 于 创建 一 个 workqueue 队列 ， 为 系统 中 的 每 个 CPU 都 创建 一 个 内 
核 线程 。 
* create_singlethread_workqueue; 用 于 创建 workqueue， 只 创建 一 个 内 核 线程 。 
* destroy_workqueue: 释放 workqueue 队列 。 
e schedule work: 调度 执行 一 个 具体 的 任务 work_struct， 执 行 的 任务 将 会 被 挂 入 Linux 
系统 提供 的 system_wq: 名 字 是 events, 
* schedule delayed, work; 延迟 一 定时 间 去 执行 一 个 具体 的 任务 ， 功 能 与 schedule. work 
类 似 ， 多 了 一 个 延迟 时 间 。 
o queue, work: 调度 执行 一 个 指定 workqueue 中 的 任务 。 
* queue, delayed work; 延迟 调度 执行 一 个 指定 workqueue 中 的 任务 ， 功 能 与 queue. work 
类 似 ， 输 入 参数 多 了 一 个 delay, 
€ queue work on; 调度 执行 一 个 指定 workqueue 中 的 任务 ， 并 在 指定 的 处 理 器 上 执行 。 
对 于 通常 的 模块 来 说 不 需要 创建 工作 队列 ， 而 是 通过 INIT. WORK 来 初始 化 静态 的 work 
_struct， 在 需要 调度 work 执行 时 (如 中 断 处 理 ISR 中 ) ， 通 过 相应 的 接口 进行 调度 即 可 。 
2. 内 核 线 程 kernel thread 
工作 队列 并 不 能 满足 所 有 的 需求 ， 男 外 工作 队列 本 身 也 是 需要 一 个 真正 的 执行 实体 的 承 
载 ， 在 内 核 中 这 个 真正 的 执行 实体 就 是 内 核 线程 kernel thread。 在 执行 ps - aux 命令 时 会 看 
到 如 下 信息 : 




















root 2 0.0 0.0 0 0? S 11:57 0:00 | kthreadd | 

root 3 0.0 0.0 0 07? S 11:57 0:00 [ ksoftirqd/O | 
root 6 0.0 0.0 0 0? S 11:57 0:00 [ migration/0 | 
root 7 0.0 0.0 0 0? S 11:57 0:00 [ watchdog/0 | 
root 8 0.0 0.0 0 0? S 11:57 0:00 [ migration/1 ] 
root 10 0.0 0.0 0 0? S 11:57 0:00 [ ksoftirqd/1 ] 
root 11 0.0 0.0 0 07? S 11:57 0:00 [ watchdog/1 | 











这 些 都 是 内 核 线程 ， 之 前 在 介绍 中 断 时 ， 介 绍 了 中 断 处理 也 提供 了 在 内 核 线程 上 执行 操 
作 的 接口 。 

内 核 线程 作为 独立 的 调度 实体 ， 对 于 内 核 模块 来 说 控制 能 力 更 强 ， 所 以 很 多 复杂 的 功能 
都 需要 通过 内 核 线程 来 执行 。 

下 面 对 内 核 线程 的 主要 接口 进行 说 明 . 
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struct task, struct * kthread_create(int( * threadfn) (void * data), 
void * data, 
const char namefmt[ ] , ... ) 


__attribute__( (format( printf, 3, 4) ) ) ; 


kthread_create 用 以 产生 内 核 线程 ， 可 以 在 所 有 处 理 器 上 运作 ,产生 后 的 内 核 线程 会 等 
待 被 wake_up_process 唤醒 或 是 被 kthread_stop 终止 。 





#define kthread_run(threadfn, data, namefmt, ... ) \ 


(uo 
struct task struct *__k — V 
= kthread, create( threadfn, data, namefmt, ## __VA_ARGS__); \ 
if(! ISERR(_k)) \ 


wake_up_process(__k); \ 


€— 9 


kthread. run 主要 用 于 产生 并 唤醒 内 核 线 程 (开发 者 可 以 省 去 要 呼叫 wake up. process 的 
动作 ) ， 其 是 基于 kthread_create， 所 以 产生 的 内 核 线 程 也 不 限于 在 特定 的 处 理 器 上 执行 。 


void kthread_bind( struct task_struct * p, unsigned int cpu) ; 


kthread_bind 用 来 将 内 核 线 程 绑 定 到 固定 的 CPU 上 ， 主 要 是 通过 设 定 CPU allowed bitm- 
ask 来 实现 ， 所 以 在 SMP 的 架构 下 ， 就 可 以 指定 给 一 个 以 上 的 处 理 吉 执行 。 





int kthread_stop( struct task, struct. * k); 


kthread_stop 用 来 暂停 通过 kthread_create 产生 的 内 核 线程 ， 并 会 等 待 内 核 线程 结束 ， 并 
f£ [n] PRX, threadfn 的 返回 值 。 
通过 这 些 接口 可 见 ， 主 要 的 内 核 线程 都 是 通过 kthread_create 创建 的 ， 下 面 来 看 看 其 具体 的 
细节 。 











struct task, struct * kthread_create(int( * threadfn) (void * data), 
void * data, 


const char namefmt| | , 


n 


struct kthread, create, info create; 


// 初 始 化 创建 信息 
create. threadfn = threadfn ; 
create. data = data; 


init_completion( &create. done) ; 


spin, lock( &kthread, create, lock) ; 
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// 添 加 到 创建 列表 中 


list_add_tail( &create. list, &kthread_create_list) ; 


spin, unlock( &kthread, create lock); 





//VW& We kthreadd 内 核 线 程 ,通过 创建 参数 创建 内 核 线 程 
wake_up_process( kthreadd_task ) ; 
/等 待 创建 完成 


wait_for_completion( &create. done) ; 


if( ! 


| 





IS ERR( create. result) ) | 
struct sched. param param = | . sched. priority =0 | ; 


va_list args; 


va start( args, namefmt) ; 
vsnprintf( create. result ~ > comm, sizeof( create. result -> comm) , 
namefmt, args) ; 
va, end( args) ; 
He 
* root may have changed our( kthreadd' s) priority or CPU mask. 
* The kernel thread should not inherit these properties. 
*/ 
sched, setscheduler nocheck( create. result, SCHED. NORMAL, &param) ; 


set, cpus allowed. ptr( create. result, cpu. all mask) ; 


return create. result ; 


可 见 ， 创 建 内 核 线 程 的 主要 任务 是 由 kthreadd 内 核 线程 来 实现 的 ，kthreadd 内 核 线程 是 
系统 的 2 号 线程 ， 主 要 的 任务 就 是 屏蔽 体系 结构 相关 的 部 分 ， 为 系统 提供 创建 内 核 线程 的 服 
务 ， 其 与 系统 初始 化 相关 的 部 分 之 前 已 经 进行 了 介绍 ， 其 具体 创建 线程 的 操作 是 通过 kernel 
thread 实现 的 ，ARM 内 的 实现 如 下 : 








pid. t kernel, thread( int( * fn) (void * ), void * arg, unsigned long flags) 


| 


struct pt. regs regs; 


memset( &regs, 0, sizeof( regs) ) ; 


regs 
regs 
regs 


regs. 


. ARM r4 = (unsigned long) arg; 

. ARM r5 = (unsigned long) fn; 

. ARM, 16 = (unsigned long) kernel. thread. exit ; 

. ARM. 17 =SVC_MODE | PSR_ENDSTATE | PSR ISETSTATE; 
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regs. ARM_pc = (unsigned long) kernel_thread_helper; 
regs. ARM_cpsr = regs. ARM, 17. | PSR_I_BIT; 


return do_fork ( flags | CLONE_VM | CLONE_UNTRACED, 0, &regs, 0, NULL, NULL) ; 
| 


可 见 ， 其 主要 是 通过 do_fork 这 一 调度 模块 的 接口 创建 的 。 
这 样 ， 内 核 线程 的 主要 功能 和 接口 就 进行 了 介绍 ， 内 核 线程 主要 提供 执行 实体 的 创建 和 
管理 服务 ， 具 体 的 业务 细节 要 由 具体 的 模块 提供 操作 接口 执行 。 


5.7 内 核 提 供 的 数据 保护 一 致 性 操作 服务 











5.7.1 数据 保护 一 致 性 操作 服务 的 需求 


Linux 内 核 的 执行 会 有 各 种 各 样 复杂 的 情况 ， 处 理 吉 技术 的 发 展 为 系统 的 执行 提供 了 更 
多 的 变数 。 多 处 理 器 、 多 流水 、 乱 序 执 行 都 对 系统 的 数据 一 致 性 有 很 大 影响 ， 在 关键 点 的 数 
据 操 作 上 ， 如 果 不 能 保证 一 致 性 ， 结 果 就 会 导致 错误 ， 甚 至 产生 严重 性 的 问题 ， 这 些 问题 对 
于 驱动 来 说 更 是 如 此 ， 如 读 取 设备 寄存 带 的 状态 值 与 实际 的 不 同时 ,设备 驱动 的 操作 必然 是 
错误 的 ， 所 以 从 系统 的 角度 ， 不 同 硬件 模块 操作 了 就 需要 保证 数据 的 一 致 性 ， 对 这 些 数据 的 操 
作 进行 保护 。 只 有 这 样 才能 保证 系统 正确 运行 。 


5.7.2. 各 种 数据 保护 一 致 性 操作 简介 


在 内 核 提 供 的 基本 服务 中 已 经 简单 介绍 了 一 些 锁 的 功能 ， 这 里 对 与 驱动 相关 的 数据 一 致 
性 保护 服务 进行 进一步 介绍 。 

1. 顺序 和 屏障 

驱动 经 常 要 涉及 很 多 读 写 操作 ， 设 备 的 读 写 操作 很 多 是 要 有 顺序 性 的 ， 对 编译 器 和 处 理 
器 来 说 并 不 能 在 之 前 就 进行 这 种 顺序 性 的 假设 ， 而 是 尽力 优化 代码 ， 相 应 的 驱动 就 需要 保证 
这 种 顺序 性 ， 这 是 矛盾 的 ， 不 过 还 好 编译 器 和 处 理 器 都 提供 了 相关 功能 来 保证 操作 的 顺序 
TE, Linux 内 核对 编译 器 和 处 理 句 的 相关 指令 和 操作 进行 了 封装 ， 提 供给 其 他 模块 使 用 ， 相 
关 的 操作 就 是 形成 一 个 屏障 ， 屏 障 保证 之 前 和 之 后 的 某 些 操作 的 顺序 性 ， 下 面 是 相关 的 接口 
及 说 明 : 

e mb() : 阻止 跨越 屏障 的 读 操作 发 生 重 排序 ， 保 证 前 后 读 操作 的 顺序 性 。 

e read, barrier depends() : 阻止 跨越 屏障 的 具有 数据 依赖 关系 的 读 操作 重 排序 。 

e wmb() : 阻止 跨越 屏障 的 写 操作 发 生 重 排序 。 

e mb() : 阻止 跨越 屏障 的 读 和 写 操作 重新 排序 。 

€ smp_rmb(); Æ SMP 上 提供 rmb( ) 功 能 ， 在 UP 上 提供 barrier( ) 功 能 。 

e smp_read_barrier_depends( ) : 在 SMP 上 提供 read_barrier_depends( ) 功 能 ， 在 UP 上 提 
供 barrier( ) 功 能 。 

* smp wmb(): Æ SMP 上 提供 wmb( ) 功 能 ， 在 UP 上 提供 barrier( ) 功 能 。 
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e smp mb(): 在 SMP 上 提供 mb( ) 功 能 ， 在 UP 上 提供 barrier( ) 功能 。 

© barrier( ) : 阻止 编译 器 跨越 屏障 对 读 或 写 操作 进行 优化 。 

2. 内 核 抢占 

Linux 内 核 提 供 了 内 核 抢占 之 后 在 一 定 程度 上 也 会 造成 数据 的 不 一 致 ， 比 如 说 进程 的 切 
换 造成 数据 访问 的 交叉 执行 ， 这 样 只 在 进程 上 下 文 的 数据 操作 可 以 考虑 通过 内 核 抢占 的 接口 
来 保证 数据 一 致 性 ， 接 口 说 明 如 下 : 

* preempt_disable( ) : 增加 抢占 计数 值 ， 从 而 禁止 内 核 抢占 。 

* preempt_enable( ) : 减少 抢占 计算 ， 并 当 该 值 降 为 0 时 检查 和 执行 被 挂 起 的 需 调 度 的 

任务 。 

* preempt_enable_no_resched( ) : 激活 内 核 抢 占 但 不 再 检查 任何 被 挂 起 的 需 调 度 的 任务 。 

e preempt_count( ) : 返回 抢占 计数 。 

这 里 的 preempt_disable( ) 和 preempt_enable( ) Z& UREIA, disable 和 enable 的 次 
数 最 终 应 该 是 一 样 的 。 

男 外 在 中 断 上 下 文 和 进程 上 下 文中 需要 的 数据 一 致 性 保护 可 以 通过 中 断 开关 解决 ， 多 处 
理 器 操作 的 数据 一 致 性 保护 可 以 通过 自 旋 锁 解 决 ， 在 实际 的 应 用 中 自 旋 锁 的 接口 提供 了 相关 
中 断 的 操作 ， 所 以 通常 都 直接 使 用 正确 的 自 旋 锁 接 口 进行 相关 的 保护 操作 。 还 有 原子 操作 和 
互 斥 锁 也 是 数据 一 致 性 保护 操作 ， 原 子 操作 主要 针对 单 变量 的 数据 ， 没 有 上 下 文 的 限制 ， 而 
互 斥 锁 通 常 是 在 多 个 进程 上 下 文中 进行 数据 一 致 性 的 保护 。 这 些 接口 都 在 内 核 基 本 服务 中 有 
简单 介绍 ， 这 里 就 不 重复 说 明了 。 

还 有 各 种 RCU (主要 差别 在 如 何 进 行 回 写 上 ) 、 读 写 锁 等 ， 通 常 都 是 针对 网 络 协议 栈 、 
文件 系统 等 有 一 定 读 写 特点 的 数据 一 致 性 保护 操作 ， 在 驱动 中 使 用 的 情况 并 不 多 ， 就 不 进行 
详 述 了 。 

总 之 对 数据 一 致 性 保护 操作 ， 是 要 在 正确 的 前 提 下 ， 尽量 根据 数据 操作 的 上 下 文 以 及 特 
点 选择 合适 的 接口 进行 操作 ， 在 完成 功能 的 基础 上 尽力 提升 性 能 。 















































5.8 小 结 





本 章 主 要 介绍 和 分 析 了 驱动 框架 的 实现 ， 以 及 Linux 内 核 为 设备 驱动 提供 的 基础 服务 。 
这 些 内 容 都 是 了 解 设备 驱动 的 基础 ， 只 有 熟悉 了 它们 才能 更 好 更 清晰 地 了 解 设备 驱动 的 机 
理 。 通 过 驱动 框架 合理 的 使 用 内 核 提 供 的 这 些 基础 服务 才能 更 好 地 实现 设备 驱动 。 

在 分 析 和 介绍 的 过 程 中 从 需求 出 发 ， 尽量 以 层次 和 功能 的 方式 进行 总 结 ， 尽 力 做 到 知道 
为 什么 这 么 做 ,这 样 在 使 用 时 才 会 有 的 放 矢 。 
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BOR 设备 驱动 之 功能 型 驱动 


本 章 主要 是 对 功能 类 设备 的 驱动 框架 进行 介绍 ， 其 中 还 会 对 应 用 层 如 何 使 用 相应 的 设备 
以 及 Android 框架 的 适 配 进行 介绍 。 





6.1 输入 设备 (input) 


6.1.1 输入 设备 需求 


输入 设备 是 提供 给 用 户 输入 数据 和 信息 的 设备 ， 是 用 户 与 设备 沟通 的 桥梁 。 键 盘 、 鼠 
标 、 摄 像 头 、 光 笔 、 手 写 输入 板 、 游 戏 杆 、 语 音 输入 装置 等 都 属于 输入 设备 。Linux 内 核 提 
供 框架 来 对 各 种 物理 的 输入 设备 进行 支持 ， 摄 像 头 、 语 音 输入 是 属于 音 视频 相关 的 功能 ， 这 
两 类 设备 的 数据 包含 大 量 的 信息 ， 它 们 有 专门 的 框架 进行 支持 。 而 其 他 如 键盘 、 鼠 标 等 输入 
言 息 偏向 控制 信息 ， 在 Linux 内 核 中 统一 由 输入 设备 Input 框架 来 支持 。 

从 物理 设备 的 角度 来 说 ， 输 入 设备 Input 框架 需要 能 够 支持 各 种 不 同类 型 的 输入 设备 。 
而 从 上 层 用 户 的 角度 ， 用 户 和 希望 能 够 屏蔽 不 同 设备 的 差异 ， 有 统一 的 接口 和 操作 方法 以 及 能 
够 接收 标准 的 数据 ， 这 也 是 需要 输入 设备 Input 框架 解决 的 问题 。 总 的 来 说 ， 输 入 设备 框架 
需要 在 多 样 的 物理 设备 和 统一 的 用 户 标 准 之 间 进 行 转换 和 平衡 。 


6.1.2 输入 设备 框架 解析 


1. 框架 总 体 设计 

从 输入 设备 框架 的 需求 可 知 ， 内 核 的 整个 输入 流程 应 该 分 为 下 层 的 各 种 输入 设备 和 上 层 
与 用 户 的 控制 信息 交互 两 个 方面 。 所 以 输入 设备 框架 重要 的 工作 应 该 是 在 管理 下 层 的 各 种 输 
入 设备 和 上 层 的 控制 信息 交互 处 理 实体 ， 并 为 用 户 层 提供 统一 的 服务 ， 内 部 框架 还 需要 能 
在 输入 设备 和 用 户 的 控制 信息 两 者 之 间 建 立 有 效 的 通道 ， 从 而 进行 信息 交互 。 

根据 这 些 目标 ， 输 入 设备 框架 的 总 体 设 计 如 图 6-1 所 示 。 

从 图 6-1 可 见 ， 输 入 设备 系统 框架 的 核心 部 分 从 底 到 上 分 为 input driver, input core 和 
event handler 三 个 部 分 。 详 细 介 绍 如 下 : 

© input driver 主要 负责 下 层 物理 输入 设备 的 驱动 及 管理 ， 每 个 具体 的 驱动 都 会 对 物理 设 

备 进行 实际 的 操作 。 

* event handler 主要 负责 为 应 用 层 提供 获得 设备 输入 的 信息 ， 将 输入 事件 以 标准 形式 提 
供给 应 用 层 ， 并 接受 应 用 层 的 控制 。 

* Input core 主要 负责 对 Input driver 和 Event handler 进行 管理 ,将 二 者 进行 匹配 并 在 二 

者 之 间 建 立 通信 的 通道 。 总 的 来 说 起 到 连接 和 桥梁 的 作用 。 

从 图 6-1 可 见 ， 对 为 用 户 开放 的 设备 文件 ， 每 个 event handler 会 有 不 同 的 设备 文件 ， 需 
要 注意 的 是 在 /dev/input/ 目 录 下 的 文件 才 是 属于 输入 设备 系统 框架 生成 的 ， 而 console 和 tty 
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Input 和 输入 子 系统 框架 










/dev/input/mice 
Idev/input/jsO /dev/input/moused /dev/console 
/deviinput/js1 /dev/input/mouse1 | |/dev/ttyn 



















/dev/input/eventO Idev/input/tsO 
/dev/input/event1 /dev/input/ts1 





Event ; 
Cinput core) driver/input/input.c 


图 6-1 输入 设备 Input 系统 框架 总 体 设计 


keyboard.c 








属于 终端 设备 类 ， 并 不 属于 输入 设备 系统 框架 对 用 户 层 开放 的 设备 。 这 也 就 是 说 ， 输 入 事件 
的 接收 者 不 是 必须 产生 针对 用 户 的 输入 ， 只 要 关心 输入 事件 的 模块 就 可 以 注册 event han- 
dler， 这 一 点 很 重要 ， 也 为 许多 功能 开放 了 监测 输入 设备 输入 进行 控制 的 接口 ， 可 以 在 内 核 
内 部 就 根据 用 户 的 某 些 输入 做 特定 的 控制 。 

根据 以 上 的 三 个 部 分 的 功能 可 见 ， 如 果 设 备 文件 是 由 输入 设备 框架 创建 的 ， 则 相应 的 应 
用 层 的 接口 上 只 有 event handler， 所 有 与 应 用 层 的 交互 都 是 通过 event handler 来 完成 。event 
handler 需要 对 应 用 层 的 使 用 者 进行 管理 ， 其 中 evdev handler 的 管理 模式 如 图 6-2 所 示 。 


c Dm 


wat | o Maipo | BM 























evdev 


驱动 程序 
irat Ea Ea E B 


图 6-2 evdev handler 用 户 管理 模式 医 
































从 图 6-2 可 见 ， 每 个 操作 文件 的 进程 都 会 对 应 一 个 evdev_client， 框 架 将 对 与 之 连接 的 
输入 设备 上 传 的 输入 事件 分 别传 人 evdev. client 进行 缓冲 与 管理 ， 保 证 用 户 进 程 的 统一 视角 , 
evdev_client 则 由 evdev 统一 管理 。struct evdev 在 evdev handler 中 代表 一 个 eventX 文件 ， 而 
struct evdev 由 event handler 指向 的 表示 连接 通道 管理 实体 input_handle 中 的 private 指示 ， 这 
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样 就 完成 了 从 抽象 的 handler 管理 到 实体 的 handler 的 转换 ， 进 而 使 得 系统 从 下 层 的 设备 层 到 
上 层 的 应 用 层 的 通路 都 是 畅通 的 。 

2. 主要 管理 实体 及 功能 

按照 子 系统 三 部 分 的 划分 ， 管 理 实体 大 体 也 分 为 三 种 ， 首 先 来 看 看 系统 对 于 下 层 input 
device 的 管理 实体 ， 细 节 如 下 : 











struct input_dev | 
// 设 备 属性 


const char * name; 








const char * phys; 
const char * uniq; 


struct input_id id; 




















// 这 里 要 支持 各 种 的 输入 设备 ,所 以 要 标记 该 输入 设备 具体 的 支持 状况 
// 能 力 表 中 设备 将 支持 的 功能 相应 的 位 标记 为 1 
unsigned long evbit[ BITS_TO_LONGS( EV_CNT) ] ; 
unsigned long keybit[ BITS_TO_LONGS( KEY_CNT) ] ; 
unsigned long relbit[ BITS_TO_LONGS( REL_CNT) ] ; 
unsigned long absbit| BITS_TO_LONGS( ABS_CNT) ] ; 
unsigned long mscbit[ BITS_TO_LONGS( MSC_CNT) ] ; 
unsigned long ledbit[ BITS. TO. LONGS( LED, CNT) |]; 
unsigned long sndbit[ BITS. TO LONGS(SND CNT) ] ; 
unsigned long ffbit| BITS. TO LONGS(FF. CNT) ] ; 
unsigned long swbit[ BITS. TO. LONGS(SW., CNT) ] ; 














unsigned int hint, events. per. packet ; 





// 设 备 特殊 的 keycode 属性 及 操作 接 


unsigned int keycodemax ; 





Ul 





unsigned int keycodesize; 


void * keycode; 


int( * setkeycode) (struct input, dev * dev, 
unsigned int scancode, unsigned int keycode) ; 
int( * getkeycode) (struct input. dev * dev, 
unsigned int scancode, unsigned int * keycode) ; 
int( * setkeycode new) (struct input, dev * dev, 
const struct input, keymap. entry * ke, 
unsigned int * old keycode) ; 
int( * getkeycode new) (struct input, dev * dev, 


struct input, keymap. entry * ke); 
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struct 


ff_device * ff; 














5 





uu 


于 重复 按键 的 操作 及 记录 





unsigned int repeat_key ; 


struct 


timer_list timer; 


int rep| REP_CNT] ; 


struct 


input, mt, slot * mt; 


int mtsize ; 


int slo 


t; 

















// FH 








struct 


/设备 保存 相关 操作 信息 


于 绝对 位 置 的 设备 记录 信息 











input absinfo * absinfo; 





unsigned long key| BITS. TO LONGS( KEY, CNT) ] ; 
unsigned long led[ BITS. TO. LONGS( LED. CNT) ] ; 
unsigned long snd[ BITS. TO LONGS(SND. CNT) ] ; 
unsigned long sw[ BITS. TO. LONGS( SW. CNT) ] ; 


























// 用 于 设备 控制 
int( * open) (struct input, dev * dev) ; 


void( 


int( * 


* close) (struct input_dev * dev) ; 


flush) (struct input, dev * dev, struct file * file); 
































/该 接口 用 于 某 事件 需要 设备 进行 特殊 操作 ,如 按 某 些 键 需 用 设备 层 亮 灯 


int( * event) (struct input, dev * dev, unsigned int type, unsigned int code, int value) ; 


// X49 





FF 设备 只 绑 定 单一 的 event handler 





struct 





input, handle __rcu * grab; 


spinlock_t event, lock; 


struct 


mutex mutex; 


unsigned int users; 


bool going, away ; 


bool sync; 


// 设 备 模 型 的 接口 


struct 


device dev; 
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// 设 备 绑 定 多 个 event handler, 这 里 和 input, handle 绑 定 进而 与 event handler 绑 定 


struct list_head h_list; 
// 整 体 的 设备 管理 
struct list_head node; 





从 input, dev 中 可 见 ， 它 的 属性 兼容 了 各 种 输入 设备 ， 主 要 是 在 底层 记录 输入 的 数据 和 
状态 ， 便 于 进行 一 定 的 重复 以 及 同时 多 事件 (同时 按键 ) 的 合并 处 理 。 
接 下 来 是 对 于 上 层 event handler 的 管理 实体 ， 细 节 如 下 : 











struct input_handler | 
// 特 定 handler 的 实例 化 管理 信息 


void * private; 





// 以 下 是 事件 相关 的 操作 接口 

// 处 理 输入 事件 的 接口 

void( * event) (struct input. handle * handle, unsigned int type, unsigned int code, int value) ; 
/过滤 的 接口 
bool( * filter) (struct input, handle * handle, unsigned int type, unsigned int code, int value) ; 
// 用 于 特殊 的 对 是 否 支 持 设 备 的 检查 

bool( * match) ( struct input, handler * handler, struct input, dev * dev) ; 

// 用 于 对 input device 和 event handler 的 绑 定 ,这 里 做 绑 定 设备 后 的 初始 化 

int( * connect) (struct input, handler * handler, struct input. dev * dev, const struct input, device 
_id * id); 

信和 设备 脱离 绑 定 

void( * disconnect) (struct input, handle * handle) ; 

// 一 般 用 于 设备 绑 定 后 的 handler start 工作 ,通常 为 null 

void( * start) (struct input_handle * handle); 




























































































信和 上 层 文件 的 接口 
const struct file operations * fops; 
// 子 设备 号 ,只 有 会 产生 设备 文件 的 handler 才 有 该 值 


int minor; 








const char * name; 











// 要 求 设备 匹配 的 能 力 信息 ,可 以 是 强制 匹配 ,也 可 以 是 广泛 匹配 。 


const struct input_device_id * id_table; 





// REK input, handle 的 信息 ,这 样 就 可 以 与 input_dev 关联 起 来 
struct list_head h_list; 


struct list_head node; 
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从 上 面 的 input handler 分 析 可 见 ， 其 中 主要 内 容 是 操作 接口 ， 并 且 也 包含 了 与 应 用 层 的 
#20 file_operations 文件 操作 。 
接 下 来 是 管理 input_dev 和 input. handler 关联 的 实体 input_handle， 具 体 的 信息 如 下 : 


struct input_handle | 
// 通 常 为 handler 的 private 用 于 进行 handler 的 event 调用 时 转换 为 实际 管理 实体 


void * private; 

















int open; 
// 关 联 的 设备 名 


const char * name; 


// REK input, dev 和 input, handler 
struct input, dev * dev; 


struct input, handler * handler; 


// 1E input, dev 的 链表 中 


struct list head d. node; 
// ÝE handler 的 链表 中 
struct list head h. node; 


ls 
这 三 部 分 管理 实体 最 终 会 根据 实际 情况 连接 成 如 图 6-3 所 示 的 形式 。 


ae i | | 




































































“USB Keyboard” “Headphone” “Power Button” “USB Mouse” input_dev list 

event 

evdev e e Q e 

A “evento” “event1” “event2” “event3” 
mousedev @ 
“mouse0” 
kbd Q e 
Á 
Sysrq 9 























input_handler list 


图 6-3 管理 实体 关系 
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从 图 6-3 可 见 ， 中 间 的 圆 点 代表 input_handle ， 相 应 的 名 字 是 设备 名 ， 而 对 于 input. dev 
和 input, handler 都 可 以 是 一 对 多 的 关系 ， 需 要 注意 的 是 所 有 的 设备 都 会 绑 定 evdev， 也 就 是 
说 evdev 是 接受 所 有 设备 绑 定 的 。 框 架 会 有 两 个 链表 分 别管 理 input. dev 和 input handle; 5j 
外 如 kdb 和 sysrq 这 两 个 event handler 都 属于 内 核 内 部 的 event handler， 用 于 内 部 模块 对 输入 
事件 的 监听 。 

事件 是 输入 设备 的 数据 流 核 心 ， 整 个 输入 设备 系统 的 处 理 都 是 围绕 这 些 事 件 进 行 的 。 不 
同类 型 的 设备 相应 的 事件 也 是 不 同 的 。 应 用 层 则 要 根据 输入 设备 的 事件 进行 相应 的 操作 ， 为 
了 给 应 用 层 统一 的 接口 ， 输 入 设备 框架 对 于 输入 事件 进行 了 规范 。 

首先 系统 规范 了 事件 类 型 。 具 体内 容 如 下 : 

e EV SYN: 用 于 标记 分 段 的 事件 ， 如 坐标 分 为 x、y、z， 实 际 是 三 个 子 事件 作为 一 个 整 

体 ， 通 过 SYN 可 将 它们 组 合 进 行 处 理 。 另 在 multitouch 的 输入 设备 根据 EV_SYN 定义 









































了 规范 ， 将 多 点 同时 的 操作 分 组 上 报 。 











e EV KEY; 用 于 支持 按键 的 事件 ， 主 要 表示 按键 的 状态 转换 。 


e EV REL; 相对 位 移 事 件 ， 主 要 用 于 鼠标 这 类 设备 。 





e EV. ABS; 绝对 位 置 事件 ， 主 要 用 于 触摸 屏 这 类 设备 。 

e EV MSC; 杂项 事件 ， 基 本 是 将 硬件 信息 直接 上 报 由 应 用 层 处 理 ， 如 传送 扫描 码 。 
e EV SW: 表示 一 些 laptop 中 二 值 的 状态 。 

e EV LED: 表示 LED 的 开关 。 

e EV_SND: 表示 一 些 单 音 的 输出 。 

e EV. REP; 用 于 自动 重复 的 事件 。 

e EV FF; 强制 feedback 事件 给 输入 设备 。 

e EV PWR; 开关 键 的 相关 事件 。 

e EV FF STATUS; 从 设备 返回 的 强制 feedbak 的 状态 信息 。 


从 这 些 事件 可 以 看 出 ， 对 于 输入 设备 框架 中 考虑 到 PC laptop 等 各 种 类 型 的 输入 设备 ， 





























还 可 以 反馈 给 设备 需要 的 指示 以 及 声音 的 相关 操作 ， 以 反映 用 户 的 操作 状态 。 典 型 的 误 和 人 式 








设备 前 五 种 事件 基本 就 能 够 涵盖 相应 的 需求 。 每 类 事件 的 具体 code 信息 可 见 input. h， 其 中 
有 详细 的 定义 。 


3. 


input device 和 event handler 的 管理 


输入 设备 子 系统 最 重要 的 实体 就 是 代表 input device 的 input_dev 和 代表 event handler 的 





input_handler。 接 下 来 看 看 系统 是 如 何 对 它们 进行 管理 的 。 





通常 
aT : 
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框架 层 都 需要 实体 的 注册 接口 ， 来 提供 添加 新 的 实体 ， 先 来 看 看 input dev 的 注册 


int input_register_device( struct input_dev * dev) 

| 
static atomic_t input, no = ATOMIC INIT(0) ; 
struct input, handler * handler; 
const char * path; 


int error; 


/ * Every input device generates EV_SYN/SYN_REPORT events. * / 
设置 SYN 事件 的 能 力 , 所 有 的 输入 设备 都 要 提供 该 能 力 
__set_bit( EV_SYN, dev -> evbit) ; 














/* KEY RESERVED is not supposed to be transmitted to userspace. 
// KEY. RESERVED 不 能 提供 给 应 用 层 所 以 清除 
__clear_bit( KEY RESERVED, dev -> keybit) ; 


/ x Make sure that bitmasks not mentioned in dev —> evbit are clean. 


input, cleanse, bitmasks( dev) ; 


J * 
* If delay and period are pre — set by the driver, then autorepeating 
* is handled by the driver itself and we don' t do it in input. c. 
*/ 
// 核 心 层 提供 auto repeat 的 功能 ， 这 里 初始 化 相关 的 属性 
init_timer( &dev —> timer) ; 
if(! dev -» rep| REP_DELAY ] && ! dev -> rep| REP. PERIOD]) | 


dev -» timer. data = (long) dev; 








dev —> timer. function = input, repeat. key; 
dev —» rep| REP. DELAY | 2250; 
dev —» rep| REP. PERIOD] 233; 





// 框 架 层 提供 默认 操作 的 接口 
if( ! dev -> getkeycode && | dev -> getkeycode new) 
dev —> getkeycode new = input, default getkeycode ; 


if( ! dev -> setkeycode && | dev -> setkeycode new) 


dev —> setkeycode_new = input, default, setkeycode ; 


dev. set. name( &dev -> dev, " input% ld" , 


(unsigned long) atomic, inc. return( &input, no) -1); 


// 添 加 到 设备 模型 ,这 里 是 底层 的 设备 ,还 没有 设备 号 
error = device_add( &dev —> dev) ; 





if( error) 


return error; 


error = mutex, lock, interruptible( &input, mutex ) ; 


if(error) | 


device, del ( &dev -> dev) ; 


*/ 


*/ 
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return error; 


// 添 加 到 列表 中 统一 管理 
list_add_tail( &dev -> node, &input_dev_list) ; 











//PEFF event handler 的 绑 定 ,handler 通过 框架 的 链表 管理 ,之 前 已 经 注册 

list_for_each_entry( handler, &input_handler_list, node) 
input_attach_handler( dev, handler) ; 

input, wakeup. procfs readers( ) ; 


mutex, unlock ( &input, mutex ) ; 


return 0; 


| 











从 代码 中 可 见 ，input device 的 内 部 属性 都 是 为 了 各 种 类 型 的 输入 设备 准备 的 ， 另 外 内 
核 还 提供 了 统一 的 操作 接口 来 进行 keycode 的 设置 ， 这 些 基本 属于 标准 操作 。 而 相应 设备 的 
分 配 通过 input_allocate_device 来 执行 。 

其 中 比较 重要 的 就 是 与 event handler 的 绑 定 ， 下 面 来 分 析 一 下 具体 的 操作 : 























static int input_attach_handler( struct input_dev * dev, struct input_handler * handler) 
| 

const struct input_device_id * id; 

int error; 

// 检 查 是 否 匹 配 , 返 回 支 持 的 id 号 

id = input_match_device( handler, dev); 

if(! id) 

return — ENODEV; 





// 建 立 input device 与 具体 handler 的 连接 
error = handler — > connect( handler, dev, id); 
if( error && error ! = - ENODEV) 
printk( KERN. ERR 
"input; failed to attach handler %s to device 96s, " 


"error; % d\n", 


handler -> name, kobject name( &dev -> dev. kobj) , error) ; 


return error ; 


| 





从 中 可 见 主要 就 进行 了 两 个 操作 : 检查 匹配 和 建立 连接 。 下 面 分 析 一 下 匹配 的 流程 : 
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static const struct input, device, id * input match, device( struct input, handler * handler, 


struct input, dev * dev) 


const struct input, device id * id; 


int 1; 





// &&^* handler 有 自己 的 匹配 表 可 以 进行 宽泛 的 匹配 和 严格 的 匹配 
for( id = handler -> id. table; id ->flags || id -> driver info; id ++ ) | 
// 通 过 对 id — flags 来 进行 严格 的 匹配 








//bustype 说 明 输 入 设备 的 连接 类 型 ,比如 与 host 直接 相连 ,还 是 通过 蓝牙 ,usb 连接 





if(id->flags & INPUT DEVICE ID MATCH, BUS) 
if( id -> bustype ! = dev -> id. bustype) 





continue ; 
人/ 以 下 要 匹配 厂商 信息 
if( id -> flags & INPUT DEVICE ID MATCH VENDOR) 
if( id -> vendor | = dev —> id. vendor) 








continue ; 


if( id -> flags & INPUT DEVICE ID MATCH. PRODUCT) 
if( id -> product | = dev -> id. product) 





continue ; 


if( id -> flags & INPUT DEVICE ID MATCH, VERSION ) 


if( id -> version | = dev —> id. version) 





continue ; 


// 能 力 匹 配 ,如 果 handler 设置 了 检查 的 能 力 位 , 则 设备 必须 有 该 能 
//event handler 的 id 表 中 不 设置 表示 不 检查 
MATCH_BIT(evbit, EV. MAX); 

MATCH. BIT(keybit, KEY. MAX) ; 

MATCH, BIT(relbit, REL MAX); 

MATCH, BIT(absbit, ABS. MAX) ; 
MATCH. BIT( mscbit, MSC, MAX) ; 

MATCH. BIT(ledbit, LED. MAX) ; 

MATCH. BIT(sndbit, SND. MAX) ; 

MATCH, BIT(flbit, FF MAX); 

MATCH, BIT(swbit, SW. MAX); 






































// handler 具体 的 匹配 接口 ,通常 为 空 
if( ! handler -> match || handler -> match( handler, dev) ) 


return id; 
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return NULL; 
| 


可 见 在 设备 与 handler 的 匹配 中 尽力 进行 匹配 ， 而 且 人 允许 进行 宽泛 的 匹配 ， 对 于 输入 设 
备 系 统 中 最 宽泛 的 匹配 就 是 evdev handler， 相 应 的 id 表 如 下 : 








static const struct input, device, id evdev_ids[ | = | 
| . driver info 21 | ,/ * Matches all devices * / 


er / * Terminating zero entry * / 


i8 


可 见 相 应 设置 很 简单 ， 只 要 driver info 设置 为 1 即 可 。 

匹配 之 后 的 操作 就 是 将 input device 与 event handle 建立 连接 ,会 调用 event handler 的 
connect 接口 函数 ， 主 要 的 工作 是 建立 input_handle， 并 通过 input_register_handle 将 相关 网 状 
连接 建立 起 来 。 

系统 的 事件 是 如 何 传送 的 呢 ? 通过 input. event 来 进行 事件 的 传送 ， 具 体 如 下 : 








void input_event( struct input, dev * dev, 


unsigned int type, unsigned int code, int value) 


unsigned long flags; 


/检查 事件 类 型 是 否 支持 
if(is event supported(type, dev —» evbit, EV. MAX)) | 








spin, lock, irqsave( &dev -> event, lock, flags) ; 

// 输 入 是 随机 事件 ,所 以 可 以 作为 系统 的 随机 源 
add_input_randomness( type, code, value); 

// 具 体 的 将 事件 转发 的 接口 

input_handle_event( dev, NULL, type, code, value); 
































spin, unlock, irqrestore( &dev -> event, lock, flags) ; 


| 





input. handle, event 会 根据 具体 的 事件 类 型 来 判断 是 向 上 层 event handler 发 送 还 是 发 送 给 
input device 或 者 两 者 都 发 送 ， 进 而 进行 对 应 的 发 送 处 理 (主要 是 调用 对 应 的 接口 函数 )。 问 
event handler 转发 最 终 通过 input, pass, event 来 实现 。 





static void input_pass_event( struct input_dev * dev, 


struct input_handler * src_handler, 
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unsigned int type, unsigned int code, int value) 


struct input_handler * handler; 


struct input_handle * handle; 


rcu, read. lock( ) ; 


/系统 可 以 设置 相应 的 输入 设备 单一 连接 event handler ,这 里 获得 相关 属性 
handle = rcu, dereference( dev -> grab) ; 

// 如 果 单 一 连接 直接 传送 事件 到 对 应 的 event handler 

if( handle ) 


handle -> handler -> event( handle, type, code, value) ; 











else | 


bool filtered = false; 


// 这 里 表示 多 连接 的 情况 ,遍历 所 有 的 连接 点 
list_for_each_entry_rcu( handle, &dev -> h list, d node) | 
if( ! handle -> open) 


continue ; 


// 获 得 相应 的 event handler 
handler = handle -> handler; 





// 这 里 表示 之 前 已 经 拒绝 了 该 事件 则 直接 跳 过 
if( handler == sre, handler) 


continue ; 


// 需 要 的 话 进行 事件 的 过 滤 
if( ! handler ->filter) | 
if( filtered ) 
break ; 
// 将 事件 转发 给 event handler 
handler -> event( handle, type, code, value) ; 








| else if( handler —> filter( handle, type, code, value) ) 


filtered = true; 


rcu, read. unlock( ) ; 
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由 于 框架 层 提供 诸如 auto repeat 等 功能 ， 所 以 也 会 使 用 input_pass_event 来 进行 事件 的 
传送 。 

为 了 设备 操作 方便 ， 系 统 还 基于 input_event 进行 了 封装 ， 为 不 同类 型 的 事件 提供 了 事 
件 转发 操作 的 标准 接口 ， 接 口 如 下 : 








static inline void input, report, key( struct input, dev * dev, unsigned int code, int value) 
static inline void input, report, rel(struct input, dev * dev, unsigned int code, int value) 
static inline void input, report, abs( struct input, dev * dev, unsigned int code, int value) 
static inline void input, report, ff status( struct input, dev * dev, unsigned int code, int value) 
static inline void input, report, switeh( struct input, dev * dev, unsigned int code, int value) 
static inline void input, sync( struct input, dev * dev) 

static inline void input, mt, sync( struct input, dev * dev) 


static inline void input, mt. slot(struct input, dev * dev, int slot) 


可 见 框 架 为 了 开发 者 的 方便 做 了 不 少 工作 ， 这 样 统一 的 接口 可 以 降低 代码 元 余 度 。 整 体 
上 框架 对 input device 和 event handler 的 管理 除了 实体 的 管理 外 还 负责 事件 的 转发 工作 。 

4. 设备 号 管理 及 设备 文件 创建 

对 为 应 用 层 提供 服务 的 框架 ， 设 备 文件 相关 的 管理 是 十 分 重要 的 ， 这 里 分 析 输 入 设备 杠 
架 相 关 的 实现 。 首 先 作 为 字符 设备 的 子 类 型 输入 设备 会 统一 注册 文件 操作 接口 ， 用 于 输入 设 
备 打开 的 管理 。 具 体 就 是 input. fops: 





























static const struct file operations input, fops = | 
. owner THIS MODULE, 
. open = input, open file, 
. llseek = noop_llseek , 


ls 


从 input. fops 中 可 见 其 主要 的 操作 就 是 open， 具体 的 分 析 如 下 : 


static int input_open_file( struct inode * inode, struct file * file) 
| 

struct input_handler * handler; 

const struct file_operations * old_fops, * new_fops = NULL; 


int err; 


err = mutex lock interruptible( &input_mutex ) ; 
if( err) 


return err; 


/ * No load -on - demand here? * / 
// 通 过 全 局 的 input_table 来 管理 框架 内 部 的 设备 ,实际 指向 的 是 event handler 
handler = input_table[ iminor( inode) >>5 ] ; 











394 


if( handler) 
new_fops = fops_get( handler -> fops ) ; 


mutex, unlock ( &input_mutex ) ; 


/%* 


* That’s _really_ odd. Usually NULL -> open means " nothing special" , 


* not "no device". Oh, well... 
*/ 
if( ! new. fops || ! new. fops -> open) | 
fops. put( new, fops) ; 
err = — ENODEV ; 


goto out ; 


// 重 载 文件 的 操作 接口 
old_fops = file ->f op; 
file -» f op = new. fops; 














// 用 新 的 接口 打开 ,如 果 失 败 则 恢复 文件 操作 接口 
err = new, fops —> open( inode, file); 
if(err) | 

fops_put( file — > f op) ; 

















file -> f op = fops_get( old. fops) ; 
} 
fops_put( old_fops) ; 
out: 


return err; 


从 分 析 可 见 ， 输 入 设备 系统 对 应 的 设备 文件 使 用 统一 的 

















主 设备 号 ， 而 子 设备 号 是 与 











event handler 相关 的 ， 不 同 的 handler 管理 不 同 的 子 设 备 号 。 有 
接口 : 





int input_register_handler( struct input_handler * handler) 
| 
struct input_dev * dev; 


int retval; 


retval = mutex_lock_interruptible( &input, mutex ) ; 
if( retval) 


return retval ; 





HRA A event handler 的 注册 
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INIT_LIST_HEAD( &handler -> h. list) ; 


// 包 含 文件 操作 接口 ,说 明 该 handler 会 对 用 户 开放 
if( handler ->fops ! 2 NULL) | 
// 加 入 input, table ,用 来 在 打开 文件 时 做 重 定 向 操作 
if( input_table[ handler -> minor >>5]) | 
retval = -上 BUSY ; 


goto out; 





























} 
// 这 里 可 见 一 个 handler 管理 32 个 设备 
input, table[ handler -> minor >>5 | = handler; 











list_add_tail( &handler -> node, &input_handler_list) ; 


list. for each, entry( dev, &input. dev, list, node) 
input, attach, handler( dev, handler) ; 


input, wakeup. procfs readers( ) ; 


out : 
mutex, unlock ( &input, mutex ) ; 


return retval ; 


这 里 不 仅 包括 对 event handler 的 管理 ， 由 于 event handler 还 要 作为 用 户 的 接口 ， 还 要 进 
行 子 设备 的 分 配 ， 只 是 输入 框架 已 经 提前 预 分 配 好 了 ， 每 个 handler 管理 32 个 设备 。 
最 后 再 来 看 具体 的 evdev handler 的 connect 操作 . 














static int evdev_connect( struct input_handler * handler, struct input_dev * dev, 


const struct input, device id * id) 


struct evdev * evdev; 
int minor; 


int error; 





// 内 部 管理 的 子 设备 号 分 配 情况 
for( minor =0; minor < EVDEV_MINORS; minor ++ ) 
if( | evdev, table[ minor] ) 
break ; 


if( minor == EVDEV. MINORS) | 
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printk( KERN, ERR "evdev: no more free evdev devices\n" ) ; 
return — ENFILE; 





// 得 到 子 设备 号 后 ,进行 管理 实体 的 分 配 
evdev = kzalloc( sizeof( struct evdev) , GFP_KERNEL) ; 
if(! evdev) 

return — ENOMEM; 





// 属 性 的 初始 化 
INIT. LIST HEAD( &evdev —> client. list) ; 





spin, lock, init( &evdev —> client, lock ) ; 
mutex, init( &evdev —» mutex) ; 
// 等 待 队 列 管理 操作 的 进程 


init_waitqueue_head( &evdev -> wait) ; 








dev_set_name( &evdev -> dev, "event% d" , minor) ; 
evdev —> exist = true; 
/记录 内 部 的 子 设备 号 


evdev -> minor = minor; 


























// 这 里 是 与 底层 input device 连接 点 的 属性 赋值 ,便于 建立 系统 内 部 的 关联 


evdev -> handle. dev = input_get_device( dev) ; 








evdev -> handle. name = dev_name( &evdev -> dev) ; 
evdev —» handle. handler = handler; 


evdev -> handle. private = evdev; 











/真正 的 设备 号 及 设备 的 初始 化 ,这 里 是 对 应 于 用 户 的 设备 











evdev —> dev. devt = MKDEV(INPUT MAJOR, EVDEV_MINOR_BASE + minor) ; 


// 功 能 类 型 设备 

evdev —> dev. class = &input_class; 

// 层 次 上 要 对 应 于 input device 的 设备 
evdev -> dev. parent = &dev —» dev; 








evdev -> dev. release = evdev_free ; 


device, initialize( &evdev -> dev) ; 


// 建 立 系统 内 部 的 关联 
error = input_register_handle( &evdev —> handle) ; 
if( error) 


goto err_free_evdev; 


// 内 部 管理 设备 
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error = evdev_install_chrdev( evdev) ; 
if( error) 


goto err unregister handle; 

















// 这 里 通知 系统 加 入 新 的 设备 ,相应 的 会 有 应 用 层 建 立 设备 文件 


error = device_add( &evdev -> dev) ; 























if( error) 


goto err. cleanup. evdev; 


return 0; 


err cleanup. evdev: 

evdev, cleanup( evdev ) ; 
err unregister handle: 

input, unregister handle( &evdev —> handle) ; 
err free evdev; 

put, device( &evdev -> dev) ; 

return error; 


| 








可 见 具体 的 设备 号 管理 还 是 在 event handler 内 部 进行 的 。 从 实现 中 设备 的 层次 设置 可 以 
了 解 到 ， 设 备 的 层次 关系 的 添加 是 逐 层 进行 的 ， 这 部 分 工作 由 各 层 独立 完成 。 


6.1.3 输入 设备 应 用 层 操作 及 框架 适 配 


应 用 层 对 输入 设备 的 基本 使 用 主要 是 集中 在 读 取 相应 的 事件 方面 ， 具 体 事 件 传 给 哪个 应 
用 则 是 属于 应 用 框架 的 范畴 ， 与 具体 的 UI 控制 紧密 关联 。 
先 来 看 看 简单 的 测试 程序 ， 对 设备 的 输入 进行 检查 并 在 控制 台 上 进行 显示 。 


















































int main(int argc, char * * argv) 
| 
int fd, rd, i, j, k; 
struct input, event ev| 64]; 
int version; 
unsigned short id[4] ; 
unsigned long bit[ EV. MAX ] | NBITS( KEY. MAX) ] ; 
char name| 256 | =" Unknown" ; 
int abs[ 5] ; 
int counter 20; 


int iterations 20; 


if(arge « 3) | 
printf( " Usage; evtest /dev/input/eventX «iterations > \n" ) ; 
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printf( " Where X = input device number\n" ) ; 


return 1; 


/L/ITDSXAHT 
if( (fd = open(argv| argc - 2], O RDONLY)) < 0) | 
perror( "evtest; cannot open node" ) ; 


return 1; 


iterations = atoi(argv| arge - 1] ) ; 
printf( " Number of iterations 96 d\n" , iterations) ; 
if(iterations « 1) | 

perror( " evtest; number of iterations shall be » 1 Vn" ) ; 


return 1; 





// 获 得 基本 信息 
if(ioctl(fd, EVIOCGVERSION, &version) ) | 
perror( " evtest; can't get version" ) ; 


return 1; 


printf( " Input driver version is % d. 96 d. % d\n" , 
version >> 16, ( version 2» 8) & Oxff, version & Oxff) ; 


ioctl(fd, EVIOCGID, id); 
printf( " Input device ID; bus 0x% x vendor 0x46 x product 0x% x version 0x% x\n" , 
id[ID BUS], id[ ID VENDOR], id[ ID PRODUCT], id[ ID VERSION]) ; 


ioctl( fd, EVIOCGNAME( sizeof( name) ) , name) ; 


printf( " Input device name; V'96sV" Wn" , name); 


memset( bit, 0, sizeof( bit) ) ; 
ioctl( fd, EVIOCGBIT(0, EV MAX), bit[0]) ; 
printf( " Supported events; n" ) ; 





// 根 据 支持 的 事件 类 型 获得 设备 能 力 并 进行 相应 的 显示 
for(i=0; i < EV_MAX; i++) 
if(test_bit(i, bit[0])) | 
printf(" Event type %d(%s)\n", i, events i] ? events[i] ; "?"); 





if( ! i) continue; 
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ioctl(fd, EVIOCGBIT(i, KEY. MAX) , bit[i] ); 
for(j =0; j < KEY_MAX; j++) 
if(test_bit(j, bit[i])) | 
printf( " Event code %d(%s)\n", j, names[i] ? (names[i][j] ? names 
WEE g APN a UE 
if(i ==EV_ABS) | 
ioctl( fd, EVIOCGABS(j) , abs); 
for(k=0; k < 5; k++) 
if((k < 3) || abs[k]) 
printf( " 95s 96 6d Wn" , absval[ k], abs[k]) ; 


printf( " Interacting 96 d times. . . (interrupt to exit) n" , 


iterations ) ; 














// 和 迭代 读 取 输入 事件 ,输出 事件 信息 ,这 里 是 block 同步 读 取 
while( counter < iterations) | 
printf( " Info ; %d of %d iterations\n" , counter, 
iterations ) ; 


rd =read( fd, ev, sizeof( struct input, event) * 64) ; 


if(rd < (int) sizeof( struct input, event) ) | 
printf " yyy\n" ) ; 
perror( " Wnevtest; error reading" ) ; 


return 1; 


for(i=0; i < rd / sizeof( struct input, event) ; i++ ) 


if( ev[ i]. type == EV, SYN) | 
printf( " Event; time 96 ld. %06ld, 96s rue 


ev[ i]. time. tv, sec, ev[ i]. time. tv. usec, ev[ i]. code ? "Config Sync" : 





Report Sync" ) ; 

| else if(ev[ i]. type == EV, MSC && ev[i]. code == MSC RAW) | 

printf(" Event; time % 1d. %06ld, type %d(%s), code %d(%s) , value 9602x n" , 

ev[ i]. time. tv. sec, ev[ i]. time. tv usec, ev[ i]. type, 
events| ev| i]. type] ? events| ev[ i]. type] : "2", 
ev[ i]. code, 
names| ev[ i]. type] ? (names[ev[ i]. type] [ ev[i]. code] ? names[ ev[ i] 
.type]llev[i].code] : "?") ; "2", 
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ev[ i]. value); 


| else | 
printf( " Event; time %ld. 9606ld, type 96 d( 96s) , code %d(%s), value 96 dWn" , 


ev[ i]. time. tv. sec, ev[ i]. time. tv. usec, ev[ i]. type, 
events| ev| i]. type] ? events[ ev[ i]. type] ; "?" 


ev[ i]. code, 
names| ev[ i]. type] ? (names[ev[ i]. type] [ ev[i]. code] ? names{ ev[ i] 


. type] [ev[i]. code] : "?") ; "2", 


ev[ i]. value); 
| 
counter ++ ; 

| 

return 0; 
| 
从 简单 的 测试 代码 可 见 ， 输 入 设备 的 操作 逻辑 基本 上 是 打开 设备 ， 检 查 设备 能 力 ， 应 用 
需要 根据 能 力 进行 相关 的 配置 。 最 后 就 是 读 取 输入 事件 转发 给 系统 的 框架 。 

接 下 来 看 看 Android 是 如 何 进行 相关 适 配 的 。 对 于 Android 框架 来 说 ,输入 设备 的 相关 
操作 是 在 EventHub 中 实现 的 ， 首 先 需要 检查 所 有 的 输入 文件 ， 其 是 通过 inotify 来 实现 的 。 
在 EventHub 的 构造 函数 中 会 对 整个 /dev/input 进行 监视 。 





























mINotifyFd = inotify_init() ; 
int result = inotify_add_watch( mINotifyFd, DEVICE PATH, IN. DELETE | IN_CREATE) ; 








从 中 可 见 ， 对 设备 创建 和 删除 都 进行 监控 ， 这 样 系统 会 对 输入 设备 有 全 局 的 把 控 ， 每 当 
有 相应 的 事件 发 生 时 都 会 调用 EventHub ::readNotifyLocked， 其 中 会 有 如 下 代码 


while( res >= ( int) sizeof( * event) ) | 
event = (struct inotify event * )(event buf + event, pos); 


if( event -» len) | 
strepy( filename, event —» name) ; 
if( event -> mask & IN, CREATE) | 


openDeviceLocked ( devname ) ; 


| else | 
ALOGI( " Removing device’ %s due to inotify event\n" , devname) ; 


closeDeviceByPathLocked ( devname) ; 


| 


event size = sizeof( * event) + event —> len; 
res — -event size; 
event pos + -event size; 
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一 旦 发 现 是 create 文件 的 时 候 会 进行 打开 设备 的 操作 ， 其 中 openDeviceLocked 会 根据 类 
似 之 前 测试 代码 的 ioctl 方式 获得 输入 设备 的 信息 ， 并 进行 相关 的 属性 配置 ， 然 后 通过 如 下 
代码 以 poll 的 方式 来 监测 设备 的 输入 : 























struct epoll_event eventItem ; 

memset( &eventltem, 0, sizeof( eventItem ) ) ; 

eventItem. events = EPOLLIN ; 

eventltem. data. u32 = deviceld ; 

if( epoll, ctl( mEpollFd, EPOLL CTL, ADD, fd, &eventltem) ) | 
ALOGE( " Could not add device fd to epoll instance. errno = 96 d" , errno); 
delete device; 


return —1; 


| 





设备 的 输入 则 是 在 EventHub : : getEvents 中 等 待 事件 的 上 报 ， 代 码 如 下 





int pollResult = epoll_wait( mEpollFd, mPendingEventItems, EPOLL_MAX_EVENTS, timeoutMillis) ; 





事件 上 报 后 getEvents 会 读 取 并 检查 确认 具体 的 有 效 事件 数目 后 返回 ， 后 续 操 作 就 是 
上 报 给 应 用 框架 层 进行 处 理 。 这 样 就 实现 了 输入 设备 的 整体 适 配 。 


6.1.4 TI 芯片 输入 设备 相关 实现 详解 


对 DM 3730 的 开发 板 ， 相 关 的 输入 设备 是 电源 管理 芯片 中 的 键盘 和 矩阵， 这 里 对 相关 的 
输入 设备 驱动 进行 分 析 。 

在 硬件 介绍 中 已 经 见 到 DM 3730 与 电源 管理 芯片 是 通过 下 C 总 线 进 行 连接 的 ， 所 以 该 键 
盘 驱 动 需要 建立 在 下 C 总 线 操作 之 上 。 

相应 的 驱动 首先 是 platform_driver， 细 节 如 下 : 
































static struct platform_driver twl4030_kp_driver = | 
. probe = twl4030_kp_probe, 
. remove = __devexit_p(twl4030_kp_remove) , 
. driver = | 
. name = " twl4030. keypad" , 
. owner = THIS MODULE, 
ll 
E 





其 中 probe 接口 是 了 解 驱动 的 入口 ， 它 是 在 总 线 进 行 匹配 之 后 进行 的 ， 主 要 进行 根据 设 
备 信息 申请 资源 以 及 驱动 相关 的 初始 化 。 下 面 进行 详细 分 析 : 











static int __devinit twl4030_kp_probe( struct platform, device * pdev) 


| 


struct twl4030_keypad_data * pdata = pdev —> dev. platform_data; 
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const struct matrix_keymap_data * keymap_data = pdata —» keymap. data; 
struct twl4030_keypad * kp; 

struct input_dev * input; 

u8 reg; 


int error; 


// f SE fe AE PE E I 4E RE fri ES REJI 0 
if( ! pdata || ! pdata -> rows || ! pdata -> cols || 
pdata -> rows > TWLA030. MAX, ROWS || pdata -> cols > TWLA030 MAX. COLS) 


dev. err( &pdev -> dev, "Invalid platform. data Wn" ) ; 
return — EINVAL; 


// 分 配 驱 动 中 设备 的 管理 实体 
kp = kzalloc( sizeof( * kp), GFP_KERNEL) ; 
// 分 配 输入 框架 的 input device 实体 
input = input, allocate device( ) ; 
if(! kp || ! input) | 
error  - ENOMEM; 








goto errl ; 


/ * Get the debug Device */ 
kp -> dbg dev = &pdev -> dev; 
// 与 输入 设备 框架 建立 关联 


kp -> input = input; 








// 记 录 设 备 信息 


kp -> n_rows = pdata —> rows; 





kp -> n. cols = pdata -> cols; 

/获得 中 断 号 ,由 于 电源 管理 忆 卢 是 通过 引 脚 对 DM 3730 进行 中 断 , 这 里 为 
// 其 提供 单独 的 中 断 号 

kp -> irq = platform, get, irq( pdev, 0) ; 


























/ * setup input device * / 
设置 键盘 事件 类 型 
__set_bit( EV. KEY, input -> evbit) ; 





/ * Enable auto repeat feature of Linux input subsystem * / 
// 根 据 设备 配置 是 否 自动 重复 
if( pdata -> rep) 
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. set bit( EV. REP, input -> evbit) ; 


// 设 置 MSC 类 型 ,提供 扫描 码 
input_set_capability( input, EV_MSC, MSC_SCAN) ; 








// 根 据 设备 信息 设置 input device 的 相关 属性 
input —> name = " TWLA030 Keypad" ; 
input —» phys = " twl4030_keypad/inputO" ; 





FH 





input —> dev. parent = &pdev —> dev; 


input —> id. bustype = BUS. HOST; 
input -> id. vendor = 0x0001 ; 
input —> id. product =0x0001 ; 
input —> id. version = 0x0003 ; 


input —> keycode = kp -> keymap; 
input -> keycodesize = sizeof( kp -> keymap[ 0] ) ; 
input -> keycodemax = ARRAY SIZE( kp -> keymap) ; 


matrix keypad, build keymap(keymap. data, TWLA030 ROW. SHIFT, 
input -> keycode, input -> keybit) ; 


// 注 册 input device 
error = input, register device( input) ; 
if(error) | 
dev. err( kp -> dbg dev, 
"Unable to register twl4030 keypad device Wn" ) ; 


goto errl ; 


error = twl4030_kp_program( kp) ; 
if( error) 


goto eri2 ; 





// Vi T 38 E P C 总 线 进 行 相关 操作 ,所 以 这 里 设置 为 线程 执行 中 断 
error = request, threaded irq( kp -> irq, NULL, do_kp_irq, 






































0, pdev -» name, kp) ; 
if(error) | 
dev. info(kp -> dbg dev, "request. irq failed for irq no = 96 d n" , 
kp -> irq) ; 


goto err2 ; 





// 这 里 使 能 键盘 上 报 中 断 

reg=(u8) ~ (KEYP IMRI KP | KEYP_IMRI_TO) ; 

if( twl4030_kpwrite_u8 (kp, reg, KEYP_IMR1)) | 
error = — EIO; 





goto err3 ; 


// 将 私有 信息 加 入 platform device 中 ,以 便 后 续 操 作 实 例 化 的 需要 
platform_set_drvdata( pdev, kp) ; 


return 0; 


| 


从 中 可 见 ， 主 要 的 流程 就 是 针对 输入 设备 框架 进行 input_dev 的 相关 初始 化 和 注册 ， 男 
外 就 是 注册 中 断 。 相 应 的 platform_device 是 通过 add_numbered_child 来 创建 的 ， 原 因 是 由 于 
电源 管理 芯片 实际 包含 音频 处 理 、 键 盘 、USB phy 等 多 种 功能 ， 在 Linux 内 核 中 将 这 类 设备 
归 为 mfd ( 即 multi function device) ， 实 际 还 是 一 个 一 个 单独 的 设备 ， 但 是 通过 统一 的 接口 进 
行 操作 ， 具 体 就 不 进行 详 述 了 。 

回 到 驱动 ， 当 有 按键 输入 时 就 会 触发 中 断 ， 进 而 执行 驱动 的 中 断 处 理 函 数 ， 内 容 如 下 : 


























static irqreturn t do_kp_irq(int irq, void * _kp) 
| 

struct twl4030. keypad * kp =_kp; 

u8 reg; 


int ret ; 


/** Read & Clear TWLA030 pending interrupt * / 
ret = twl4030_kpread( kp, &reg, KEYP ISRI, 1); 


if(ret >=0 &&(reg & KEYP IMRI. KP)) 
twl4030, kp. scan( kp, false) ; 
else 


twl4030, kp. scan( kp, true); 


return IRQ. HANDLED; 
| 


其 中 主要 的 操作 就 是 读 取 扫描 码 ， 具体 由 twl4030_kp_scan 来 实现 。 
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static void twl4030_kp_scan( struct twl4030_keypad * kp, bool release, all) 
| 

struct input, dev * input = kp -> input; 

ul6 new_state| TWL4030_MAX_ROWS]; 


int col, row; 


if( release, all) 
memset( new. state, 0, sizeof( new, state) ) ; 
else | 
/ * check for any changes */ 
// RoW FEE SERE EAR ASE Ub, 38 3t T C. 总 线 进行 
int ret = twl4030_read_kp_matrix_state(kp, new, state) ; 




















if(ret < 0)/ * panic... */ 


return ; 


if( twl4030_is_in_ghost_state(kp, new. state) ) 


return; 


/ * check for changes and print those * / 
/根据 变化 获得 扫描 码 
for(row 20; row < kp—>n_rows; row ++) | 


int changed = new_state| row] ^ kp —» kp. state[ row | ; 


if( ! changed) 


continue ; 


/ * Extra column handles "all gnd" rows */ 
for(col 20; col < kp-»n cols + 1; col++) | 


int code; 


if( ! (changed &(1 « « col))) 


continue ; 


dev. dbg( kp -> dbg dev, "key [%d:%d] 96sWn" , row, col, 


(new. state[ row] &(1 < < col)) ? 


"press" : "release" ) ; 
// 获 得 扫描 码 
code = MATRIX_SCAN_CODE(row, col, TWI4030_ROW_SHIFT) ; 
/上 报 扫描 码 


input event(input, EV MSC, MSC SCAN, code) ; 
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// 上 报 预 设 的 键 值 
input, report, key( input, kp -> keymap| code] , 
new, state[ row] &(1 < < col) ); 
} 
/记录 新 的 状态 
kp —>kp_state[ row] = new_state[ row | ; 
| 
// 一 次 完整 的 事件 所 以 上 报 SYN 


input, sync( input) ; 





Iinl 


pr 


ft 








| 


对 键盘 来 说 按 下 与 抬 起 都 是 事件 ， 所 以 在 进行 事件 检查 时 是 根据 变化 进行 确认 ， 而 不 是 
简单 的 根据 值 进 行 确认 。 具 体 获 得 相关 信息 的 方法 都 是 通过 类 似 twl4030_read_kp_matrix 
state 的 操作 完成 的 ， 其 中 会 进行 实际 的 了 C 总 线 操作 ， 有 具体 的 细节 会 在 总 线 部 分 进行 介绍 。 
在 驱动 获得 硬件 的 信息 后 就 是 向 输入 设备 框架 汇报 相应 的 事件 ， 框 架 会 上 传 给 event han- 
dler， 最 终 被 用 户 读 取 。 这 样 输 入 的 通道 就 从 硬件 到 应 用 层 打 通 了 。 


6.1.5 输入 设备 电源 管理 相关 说 明 


关于 具体 的 电源 管理 ， 先 来 看 看 框架 层 提 供 了 哪些 内 容 。 由 于 这 是 功能 型 设备 ， 所 以 电 
源 管理 主要 是 在 设备 层面 ， 来 看 看 input device 分 配 时 的 具体 操作 : 






































dev —> dev. type = &input_dev_type; 


dev -> dev. class = &input_class ; 


主要 是 设置 了 设备 类 型 以 及 设备 功能 类 ， 下 面 来 看 看 设备 类 型 input_dev_type 的 内 容 











static struct device_type input_dev_type = | 
. groups = input_dev_attr_groups, 
. release = input, dev. release, 
. uevent = input. dev. uevent, 
#ifdef CONFIG. PM 
. pm = &input. dev. pm ops, 
#endif 
iS 


可 见 其 中 包含 电源 管理 的 功能 input. dev. pm. ops, ZH T 4 P: 


static const struct dev_pm_ops input_dev_pm_ops = | 





. suspend = input_dev_suspend , 
. resume = input, dev resume, 
. poweroff = input, dev. suspend , 


. restore = input, dev resume, 
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看 一 下 具体 的 接口 内 容 : 


static int input, dev, suspend( struct device * dev) 


| 
struct input_dev * input_dev =to_input_dev( dev); 


mutex_lock( &input_dev -> mutex) ; 


// 如 果 有 使 用 者 进行 输入 设备 警示 类 的 操作 ,需要 设备 支持 


if( input_dev -> users) 








input, dev. toggle( input, dev, false) ; 
mutex, unlock ( &input, dev -> mutex) ; 


return 0; 


static int input, dev. resume( struct device * dev) 


| 


struct input_dev * input_dev =to_input_dev( dev); 


// 显 示 的 reset 设备 ,以 便 后 续 的 操作 


input, reset, device( input, dev) ; 


return 0; 


| 
可 见 在 框架 层 ， 并 没有 进行 实际 的 电源 管理 操作 ， 而 是 起 到 提示 以 及 保证 设备 正常 使 用 
的 作用 。 
对 于 物理 设备 的 电源 管理 部 分 ， 以 GPIO 键盘 为 例 ， 其 中 提供 了 电源 管理 相关 的 接口 如 下 : 














static const struct dev_pm_ops gpio_keys_pm_ops = | 





. suspend = gpio_keys_suspend , 
. resume = gpio keys resume, 


l; 
这 里 是 系统 待机 (suspend) 操作 和 恢复 (resume) 操作 的 接口 ， 下 面 来 看 看 具体 的 细节 : 








static int gpio_keys_suspend( struct device * dev) 
| 
struct platform device * pdev = to_platform_device( dev) ; 
struct gpio keys platform data * pdata = pdev -> dev. platform_data; 


int 1; 
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// RAE FE AT SC. SCF T DARE 
if( device_may_wakeup( &pdev -> dev) ) | 





for(i=0; i < pdata -> nbuttons; i++) | 
struct gpio, keys, button * button = &pdata -> buttons[ i ] ; 
if( button -> wakeup) | 
// 该 GPIO Yy Ic EE DU T CER JE FE P SÉ PE BE 


int irq = gpio. to. irq( button -> gpio) ; 





enable irq. wake( irq) ; 


return 0; 


static int gpio. keys, resume( struct device * dev) 

| 
struct platform device * pdev =to_platform_device( dev) ; 
struct gpio keys drvdata * ddata = platform, get, drvdata( pdev) ; 
struct gpio keys platform data * pdata = pdev -> dev. platform data; 


int 1; 


for(i=0; i < pdata -> nbuttons; i++) | 


struct gpio, keys button * button = &pdata —> buttons i ] ; 
/关闭 相应 的 唤醒 能 
if( button —» wakeup && device, may, wakeup( &pdev -> dev) ) | 
int irq = gpio_to_irq( button -> gpio) ; 
disable irq- wake( irq) ; 











// 检 查 GPIO 键 的 状态 ,需要 的 话 进行 上 报 
gpio_keys_report_event( &ddata -> data[ i] ) ; 
} 
上 /报告 SYN 表示 完整 的 事件 


input, sync( ddata -> input) ; 


return 0 ; 





具体 设备 根据 是 否 唤 醒 的 需要 进行 相应 的 设置 ， 从 而 完成 电源 管理 相关 功能 。 
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6.2 ” 帧 缓冲 (frame buffer) 


6.2.1 帧 缓冲 设备 需求 

对 计算 机 以 及 嵌入 式 设 备 来 说 ， 显 示 设 备 都 是 重要 的 输出 设备 ， 其 承载 了 系统 针对 用 户 
的 UL 输出， 对 用 户 体验 至 关 重 要 。 从 用 户 体验 来 看 ， 显 示 设 备 的 分 辩 率 是 重要 的 一 个 指标 ， 
分 辨 率 越 高 显示 效果 越 好 ， 随 着 技术 的 发 展 ， 显 示 设 备 的 分 辩 率 也 是 越 来 越 高 。 主 要 的 分 辩 
率 的 指标 如 图 6-4 所 示 。 


























P a 
F 


f 7 dise on 7 | 
reel | Ss 
1280 x 1024 | —7 ) | 





























Kle-4 分辨 率 指标 
从 图 6-4 可 见 ， 目 前 各 种 显示 分 辨 率 ， 不仅 大 小 不 同 ， 长 宽 比 (圆圈 中 的 比值 表示 长 
宽 比 ) 也 是 各 种 各 样 的 ， 这 些 分 辩 率 主要 有 两 种 不 同 的 标准 ， 一 种 是 4:3 的 PC 相关 的 显示 
器 标准 ， 另 外 一 种 是 16:9 的 TV 相关 的 标准 。 对 显示 驱动 基本 的 需求 就 是 能 够 支持 这 些 各 种 
不 同 分 辩 率 和 长 宽 比 的 显示 设备 ， 并 对 这 些 设备 进行 相应 的 控制 ， 使 得 系统 能 有 较 好 的 输出 
效果 。 
随 着 技术 的 发 展 ， 显 示 器 硬件 也 在 不 断 地 变化 ， 作 为 外 部 显示 设备 ， 与 处 理 器 总 是 通过 
某 种 接口 进行 连接 ， 一 方面 是 标准 的 不 同 ， 另 一 方面 是 技术 的 发 展 。 由 于 处 理 需 到 显示 器 的 
硬件 连接 方式 的 不 同 与 变化 ， 所 以 对 显示 驱动 来 说 ， 还 要 能 够 文 持 这 些 不 同 的 硬件 的 连接 方 
式 ， 并 且 将 这 些 差 别 保存 在 内 部 ， 使 得 用 户 感受 不 到 这 些 不 同 ， 给 用 户 统一 的 体验 。 
470 
































以 上 主要 是 从 基本 硬件 的 角度 产生 的 需求 ， 而 对 用 户 体 验 的 追求 也 不 断 提升 显示 硬件 的 技 
术 水 平 ， 比 如 透视 效果 等 。 这 也 就 需要 在 驱动 层面 支持 相应 的 效果 设置 。 如 果 从 用 户 体 验 的 角 
度 考 虑 扩展 就 会 增加 需求 ， 比 如 能 够 支持 分 屏 显 示 、 扩 展 显示 、 支 持 显示 器 动态 切换 等 ， 这 些 
类 型 的 需求 同样 是 整个 系统 的 需求 ， 所 以 在 具体 的 实现 方案 和 层次 方面 可 以 不 必 在 设备 层 支 
持 ， 究 竟 如 何 实现 则 要 从 硬件 能 力 和 整体 的 角度 考虑 ， 这 就 仁者 见 仁 、 智 者 见 智 了 。 


6.2.2 ” 帧 缓冲 框架 解 术 


Linux 内 核 中 帧 缓冲 对 应 的 就 是 显示 输出 设备 ， 它 是 从 一 个 包含 了 完整 显示 帧 数据 的 内 
存 缓冲 区 来 驱动 视频 显示 器 。 主 要 是 将 显示 设备 抽象 为 显示 的 内 容 ， 通 过 显示 内 容 来 对 显示 
设备 进行 操作 。 从 层次 上 考虑 对 用 户 可 见 的 是 不 同 的 显示 内 容 ， 而 物理 显示 设备 的 控制 则 由 
驱动 进行 处 理 ， 当 然 用 户 不 能 对 物理 设备 的 参数 一 无 所 知 ， 由 于 应 用 层 控制 显示 内 容 和 效 
果 ， 所 以 相应 的 也 需要 获得 显示 参数 。 而 从 驱动 的 角度 考虑 ， 只 要 将 显示 内 容 统一 的 看 作 数 
据 就 可 以 在 抽象 操作 上 将 分 辩 率 等 物理 参数 的 不 同 屏蔽 ， 毕 竟 那 些 参 数 偏向 于 控制 显示 设备 
的 信息 。 

整体 的 frame buffer 框架 如 图 6-5 所 示 。 
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[X 6-5 frame buffer 框架 
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从 图 6-5 中 可 见 ， 对 框架 来 说 ， 由 于 显示 设备 还 可 以 显示 控制 台 的 信息 ， 所 以 专门 提 















































的 设备 内 存 很 少 〈 由 于 当时 价格 昂贵 ) ， 而 显示 设备 每 个 像素 








供 fbcon 来 进行 统一 的 相关 操作 ， 并 与 console 模块 相 结合 ， 而 fbemap 存在 的 原因 是 由 于 老 


的 色彩 相对 丰富 ， 所 以 建立 一 





个 映射 表 ， 使 得 用 较 少 的 信息 表示 颜色 在 内 存 的 色彩 值 ， 并 与 显示 设备 的 色彩 值 之 间 建 立 映 
射 ， 以 达到 更 好 的 显示 效果 。 这 两 部 分 使 用 并 不 多 ， 所 以 不 做 介绍 。 框 架 的 主要 部 分 是 fb- 





























mem, ， 而 相应 与 驱动 的 关系 也 是 很 直接 的 。 


























T fit frame buffer 的 框架 还 要 先 从 为 用 户 提供 的 接口 开始 。frame buffer 提供 了 相应 的 文 


件 操作 接口 fb_fops， 下 面 来 看 看 具体 内 容 : 


static const struct file_operations fb_fops = | 
. owner = THIS MODULE, 
. read = fb_read , 
. write = fb. write, 
. unlocked, ioctl = fb, ioctl , 
#ifdef CONFIG_COMPAT 
. compat_ioctl = fb. compat. ioctl , 
#endif 
. mmap = fb_mmap, 
. open = fb open, 
. release = fb. release, 
#ifdef HAVE ARCH, FB UNMAPPED AREA 
. get unmapped. area = get fb unmapped area, 
#endif 
#ifdef CONFIG_FB_DEFERRED_IO 
. fsyne = fb_deferred_io_fsync , 
#endif 
. llseek = default_Ilseek , 
E 
对 于 直接 对 应 驱动 的 框架 ， 只 要 了 解 相应 的 open 操作 就 外 
下 面 来 看 看 fb_open, WJH fb. open 说 明文 件 的 相关 操作 已 经 习 
操作 fb_fops。 

















static int 
fb_open( struct inode * inode, struct file * file) 
. acquires ( &info -> lock ) 
. releases( &info -> lock ) 
| 
int fbidx = iminor( inode ) ; 
// 这 里 fb. info 就 是 管理 的 核心 实体 
struct fb_info * info; 

















int res =0; 
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BAA Wi HES E JB SC B FA o 
E 2X 7J frame buffer 框架 的 文件 





if( fbidx >= FB. MAX) 
return - ENODEV ; 


// 根 据 子 设备 号 获得 相应 的 


me 
3 
X 








info = registered fb|[ fbidx | ; 
// 没 有 的 话 实 体 加 载 驱 动 


if( | info) 


request, module( " fb% d" , fbidx) ; 








// 再 检查 一 遍 











info = registered fb|[ fbidx | ; 
// 这 里 没有 就 真 的 没有 了 

















if( ! info) 


return - ENODEV; 
mutex, lock ( &info —> lock) ; 


if( ! try. module, get( info -> fbops -> owner) ) | 


res = — ENOD 
goto out; 


| 


// E] vfs 加 入 frame buffer fi 


EV; 


file -> private, data = info; 
// 进 行 具体 驱动 的 open 操作 
if( info —> fbops —> fb. open) | 


























匡 架 的 私有 信息 ,相当 于 实体 化 


res = info -> fbops — > fb. open( info,1) ; 


if( res) 


module. put( info —» fbops -> owner) ; 


| 


#ifdef CONFIG_FB_DEFERRED_IO 


if( info -> fbdefio) 


fb. deferred. io. open( info , inode ,file) ; 


#endif 


out : 


mutex, unlock ( &info — > lock ) ; 


return res; 








从 代码 中 可 以 了 解 ，frame buffer TEAR Az H 


H fbops。 接 下 来 分 析 一 下 fb 


struct fb. info| 
// f& frame buffer # 
int node; 
int flags; 


struct mutex lock; 


| info H 


ER EE 








ERU index 号 


EE 要 的 实体 就 是 fb_info ， 其 中 涉及 驱动 的 操作 接 


/ * Lock for open/release/ioctl funcs * / 
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作 接 
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struct mutex mm_lock; 


// 显 示 相 关 的 可 变 信息 


/ * Lock for fb_mmap and smem_ * fields * / 


struct fb_var_screeninfo var; / * Current var * / 





/7 显示 相关 的 固定 信息 








struct fb_fix_screeninfo fix; / * Current fix * / 

struct fb_monspecs monspecs ; / * Current Monitor specs * / 
struct work, struct queue; / * Framebuffer event queue * / 
struct fb_pixmap pixmap; / * Image hardware mapper * / 
// SCPERSE ES IM BU , 10€ EE ee SUP VA 3 E 


struct fb. pixmap sprite 





// color map 信息 


struct fb. cmap cmap; 


// 支 持 模 式 的 列表 


; / * Cursor hardware mapper * / 


/ * Current cmap * / 


struct list head modelist; / * mode list * / 


// 当 前 的 显示 模式 


struct fb_videomode * mode; / * current mode * / 


// 设 备 驱动 的 操作 
struct fb_ops * fbops; 
// 设 备 模 型 的 层次 
struct device * device; 
struct device * dev; 


int class_flag; 


/ * This is the parent * / 
/ * This is this fb device * / 
/ * private sysfs flags * / 


#ifdef CONFIG_FB_TILEBLITTING 
/高 级 的 设备 支持 瓦 片 级 别 的 操作 接口 ,一 个 瓦 片 是 nxan 的 矩阵 , 可 以 不 是 连续 内 存 


struct fb. tile ops * tileops; / * Tile Blitting * / 


#endif 


//frame buffer 设备 的 显存 基地 址 


char __iomem * screen, base; / * Virtual address * / 





unsigned long screen s 


void * pseudo, palette ; 


ize; / * Amount of ioremapped VRAM or 0 * / 
/ * Fake palette of 16 colors ** / 


#define FBINFO. STATE RUNNING 0 
#define FBINFO. STATE SUSPENDED 1 


u32 state; 


区 





其 中 最 重要 的 三 个 属性 分 另 
口 。 先 来 看 看 可 变 信 息 : 





struct fb_var_screeninfo | 


/ * Hardware state i. e suspend * / 





I var, fix 和 fbops， 分 别 代表 可 变 信 息 、 固 定 信息 和 驱动 操 


// 当 前 显示 的 分 辨 率 大 小 


__u32 xres; 


_ u32 yres; 


/ * visible resolution * / 





// 根 据 分 配 的 frame buffer 空间 计算 的 整个 分 辨 率 


_ u32 xres virtual ; 


_ u32 yres, virtual ; 
// 当 前 在 frame buffer 23 [R] H 





_ u32 xoffset ; 
_ u32 yoffset ; 











/每 个 像素 所 占 bit 数目 
__u32 bits per pixel; 








_ u32 grayscale; 


// RGB 以 及 透 传 参数 在 像素 bis 中 的 布局 信息 


struct fb_bitfield red; 
struct fb. bitfield green; 
struct fb. bitfield blue; 
struct fb. bitfield transp; 


. u32 nonstd; 


. u32 activate; 


__u32 height; 
. u32 width; 


_ u32 accel flags; 


/ * virtual resolution * / 


FAR JE virtual resolution 的 偏 移 


/ * offset from virtual to visible * / 


/ * resolution ** / 


/ * guess what * / 


/ * |=0 Graylevels instead of colors * / 





/ * bitfield in fb mem if true color, * / 


/ * else only length is significant * / 


/ ** transparency * / 


/ * Y-0 Non standard pixel format * / 


/ * see FB ACTIVATE * */ 


/ * height of picture in mm * / 


/ * width of picture in mm * / 


/ * (OBSOLETE) see fb. info. flags * / 


/ * Timing; All values in pixclocks , except pixclock( of course) * / 




















/这 里 是 硬件 信号 的 信息 主要 包括 像素 时 钟 .前 消 隐 后 消 隐 以 及 水 平 同步 长 度 











/垂直 同步 长 度 等 信息 
_ u32 pixclock; 





_ u32 left margin; 
_ u32 right, margin; 
_ u32 upper margin; 
_ u32 lower margin; 
__u32 hsync_len; 
__u32 vsync_len; 

_ u32 sync; 

. u32 vmode; 

__u32 rotate; 


_ u32 reserved[ 5 | ; 


/ * pixel clock in ps( pico seconds) * / 
/ * time from sync to picture * / 
/ * time from picture to sync * / 


/ * time from sync to picture * / 


/ * length of horizontal sync * / 

/ * length of vertical sync * / 

/ * see FB SYNC. * */ 

/ *see FB VMODE * */ 

/ * angle we rotate counter clockwise * / 


/ * Reserved for future compatibility * / 
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fb_var_screeninfo 会 在 frame buffer 的 操作 中 发 生 改变 ， 其 中 主要 分 辨 率 的 关系 如 图 6-6 
所 示 。 在 实际 显示 过 程 中 通过 调整 这 些 参数 可 以 显示 不 同 的 内 容 ， 也 是 利用 该 部 分 实现 多 帧 
操作 ， 提 高 整个 的 显示 效果 。 


xres_virtual/yres_virtual in fo_var_screeninfo | 





yoffset 





xres/yres in fb var screeninfo 
xoffset — — — —» 























图 6-6 mnpJ4 Jp HEISE AS 
硬件 信息 的 含义 如 图 6-7 所 示 。 图 6-6 5| E (DM 3730 芯片 手册 》 中 第 1722 页 的 框图 。 





HSW([7:0] (IHS=0) 
(pixel clock cycle unit) 
HS Fi 
ae a ' vBP[11:0] 
(line clack cycle unit) 
LPP[10:0] 
hi (line unit) 
Ei Ec VFP[11:0] 
VSW[LO] (VS=0) XT P O., {line clock cycle unit) 
(line clock cycle unit) Y. 
NE CONES. 
HBP[11:0] HFP[11:0] 
(line clock cycle unit) (pixel clock cycle unit) 


P 图 6-7 可 变 参 数 中 硬件 信息 的 含义 
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固定 信息 是 在 frame buffer 的 操作 过 程 中 并 不 发 生变 化 的 。 具 体 如 下 : 


struct fb_fix_screeninfo | 




















char id[ 16] ; / * identification string eg " TT Builtin" * / 
// 分 配 内 存 空间 的 物理 地 址 ,用 于 驱动 操作 
unsigned long smem_start; / * Start of frame buffer mem * / 


/ * (physical address) * / 






































. u32 smem_len; / * Length of frame buffer mem * / 
// 设 备 类 型 ,通常 都 是 packed pixel 
_ u32 type; / * see FB TYPE * */ 
_ u32 type aux; / * [nterleave for interleaved Planes * / 
/视觉 效果 主要 是 色彩 数 
__u32 visual; / * see FB VISUAL * */ 
// 这 里 是 进行 显示 内 容 时 相对 frame buffer 虚拟 分 辩 率 的 偏 移 最 小 像素 单位 
__ul6 xpanstep ; / * zero if no hardware panning * / 
__ul6 ypanstep ; / * zero if no hardware panning * / 
__ul6 ywrapstep ; / * zero if no hardware ywrap * / 
__u32 line length; / ** length of a line in bytes * / 
unsigned long mmio, start; / * Start of Memory Mapped I/O * / 

/ * (physical address) * / 
__u32 mmio len; / * Length of Memory Mapped I/O * / 
__u32 accel; / * Indicate to driver which * / 


/ * specific chip/card we have * / 


__ul6 reserved [3 | ; / * Reserved for future compatibility * / 


l; 


其 中 主要 的 就 是 物理 地 址 信息 。 
接 下 来 就 是 驱动 的 重点 一 一 操作 接口 : 











ipm 


struct fb. opsí 
/ * open/release and usage marking * / 
struct module * owner; 
// 打 开 和 释放 的 操作 
int( * fb. open) (struct fb. info * info, int user) ; 
int( * fb. release) ( struct fb, info * info, int user) ; 


/ * For framebuffers with strange non linear layouts or that do not 
* work with normal memory mapped access 
*/ 

// 特 殊 的 内 存 布 局 使 用 的 接口 


ssize t( * fb. read) ( struct fb. info * info, char __user * buf, 





size t count ,loff t * ppos) ; 


ssize_t( * fb. write) (struct fb. info * info, const char | user * buf, 
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size_t count ,loff t * ppos) ; 


/ ** checks var and eventually tweaks it to something supported, 
* DO NOT MODIFY PAR * / 
// 设 备 检查 可 变 参 数 


int( * fb_check_var) ( struct fb_var_screeninfo * var, struct fb_info * info) ; 





/ * set the video mode according to info —> var * / 


int( * fb. set. par) (struct fb. info * info) ; 


/ * set color register * / 
// 设 置 设备 寄存 器 接口 


int( * fb_setcolreg) ( unsigned regno , unsigned red, unsigned green, 





unsigned blue, unsigned transp ,struct fb. info * info) ; 


/ * set color registers in batch * / 
// 设 置 color map 3€ 
int( * fb. setemap) (struct fb. emap * cmap, struct fb. info * info) ; 


/ ** blank display * / 
// blank/unblank 显示 需 
int( * fb. blank) (int blank , struct fb. info * info) ; 


/ * pan display * / 
/用 于 刷新 显示 内 容 
int( * fb. pan display) ( struct fb_var_screeninfo * var, struct fb. info * info) ; 























/ * Draws a rectangle * / 

//TE frame buffer 的 内 存 空间 进行 2D 的 操作 ,可 以 通过 设备 加 速 

void( * fb. fillrect) (struct fb. info * info, const struct fb_fillrect * rect) ; 

/ * Copy data from area to another * / 

void( * fb. copyarea) (struct fb. info * info, const struct fb, copyarea * region) ; 
/ * Draws a image to the display * / 


void( * fb. imageblit) (struct fb. info * info, const struct fb. image * image) ; 


/ * Draws cursor ** / 


int( * fb. cursor) (struct fb. info * info, struct fb. cursor * cursor) ; 


/ * Rotates the display * / 
/显示 旋转 
void( * fb. rotate) (struct fb. info * info,int angle) ; 


/ * wait for blit idle , optional * / 
int( * fb. sync) (struct fb. info * info) ; 


/ ** perform fb specific ioctl( optional) * / 
// 设 备 特殊 的 ioctl 接口 
int( * fb_ioctl) (struct fb, info * info, unsigned int cmd, 


unsigned long arg) ; 


/ * Handle 32bit compat ioctl( optional) * / 
int( * fb. compat, ioctl ) (struct fb, info * info, unsigned cmd, 


unsigned long arg) ; 


/ ** perform fb specific mmap * / 
// 设 备 特殊 的 frame buffer 空间 映射 


int( * fb. mmap) (struct fb. info * info, struct vm, area, struct * vma) ; 


/ * get capability given var * / 
void( * fb. get. caps) (struct fb. info * info, struct fb_blit_caps * caps, 


struct fb. var. screeninfo * var) ; 


/ * teardown any resources to do with this framebuffer * / 


void( * fb. destroy ) (struct fb. info * info) ; 


/ * called at KDB enter and leave time to prepare the console * / 
int( * fb. debug enter) (struct fb. info * info) ; 
int( * fb. debug leave) (struct fb, info * info) ; 

E 











以 上 是 主要 的 管理 实体 ， 相 应 的 frame buffer 框架 还 提供 了 重要 的 管理 接口 ， 用 于 驱动 
使 用 。 





struct fb. info * framebuffer_alloc( size_t size ,struct device * dev) 


| 














// 这 里 为 了 访问 效率 进行 对 齐 pad 
#define BYTES_PER_LONG( BITS_PER_LONG/8) 
#define PADDING( BYTES. PER, LONG - (sizeof( struct fb. info) % BYTES PER, LONG) ) 


int fb. info size = sizeof( struct fb. info) ; 





struct fb. info * info; 


char * p; 


if( size) 
Íb info size + = PADDING; 
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// 4] HC fb. info 的 空间 ,这 里 的 大 小 是 包含 设备 特殊 信息 的 大 小 
// 形 成 统一 空间 ,前 面 是 标准 的 fb. info ,后 面 是 设备 特殊 信息 
p = kzalloc(fb_info_size + size, GFP. KERNEL) ; 
if 1p) 

return NULL; 


info = (struct fb. info * )p; 
if( size) 


info —» par = p fb. info. size; 


/初始 化 地 _info 的 设备 关联 ,关联 到 实体 化 的 设备 


info —» device = dev; 





#ifdef CONFIG_FB_BACKLIGHT 
mutex, init( &info —» bl_curve_mutex) ; 
#endif 


return info; 
#undef PADDING 
#undef BYTES_PER_LONG 
| 


这 是 对 frame buffer 管理 实体 的 分 配 操作 ， 其 中 会 初始 化 设备 的 信息 。 另 一 个 重要 的 接 
口 就 是 注册 ， 一 般 是 在 进行 相应 的 设置 之 后 执行 。 具 体内 容 如 下 : 




















int register_framebuffer( struct fb. info * fb. info) 
int 1; 
struct fb. event event; 


struct fb. videomode mode; 


/注册 数目 已 经 达到 最 大 则 报错 
if(num_registered_fb == FB. MAX) 
return — ENXIO; 


if( fb. check. foreignness( fb. info) ) 
return — ENOSYS; 


remove, conflicting framebuffers( fb. info -> apertures , fb_info -> fix. id, 


fb_is_primary_device(fb_info) ) ; 
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// 新 注册 

num, registered fb ++ ; 

/获得 管理 空间 

for(i=0 ;i<FB_MAX;i++) 
if( | registered, fb[i]) 

break ; 

// 标 记 管 理 的 index 

fb_info -> node =i; 

mutex, init( &fb info —> lock) ; 


mutex, init( &fb. info -> mm lock) ; 

















// 创 建设 备 模 型 的 设备 实体 ,这 里 会 包括 设备 号 ,通知 应 用 层 创建 设备 文件 
fb. info — > dev = device. create( fb_class ,fb_info —» device, 
MKDEV(FB_MAJOR,i) , NULL," fb?o d" ,iD ; 

if(IS ERR(fb. info -> dev) ) | 

/ * Not fatal * / 

printk( KERN, WARNING "Unable to create device for framebuffer 96 d; errno = 96 ld Vn" , i, 

PTR, ERR( fb. info -> dev) ) ; 

fb. info -> dev = NULL; 

| else 


fb. init. device( fb info) ; 




















// 初 始 化 pixmap 的 信息 
if(fb_info -> pixmap. addr == NULL) | 
fb. info -> pixmap. addr = kmalloc( FBPIXMAPSIZE , GFP_KERNEL) ; 
if( fb. info -> pixmap. addr) | 
fb info -> pixmap. size = FBPIXMAPSIZE ; 
fb info -> pixmap. buf align 21; 
fb info -> pixmap. scan. align = 1; 
fb info -> pixmap. access. align 232; 
fb info -> pixmap. flags = FB PIXMAP DEFAULT; 


| 
fb. info —» pixmap. offset =0; 


if( ! fb. info -> pixmap. blit, x) 
fb. info -> pixmap. blit x = ~ (u32)0; 


if( ! fb. info -> pixmap. blit. y) 
fb. info -> pixmap. blit y = ~ (u32)0; 


if( | fb. info -> modelist. prev || ! fb. info -> modelist. next) 
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INIT_LIST_HEAD( &fb info -> modelist) ; 








// 根 据 可 变 信息 添加 标准 的 mode 
fb_var_to_videomode( &mode , &fb_info -> var) ; 
fb_add_videomode( &mode , &fb_info -> modelist ) ; 
// 加 入 系统 管理 中 

registered_fb[ i] —fb info; 





// 通 知 其 他 模块 有 frame buffer 设备 注册 
event. info = fb_info; 
if( ! lock. fb. info( fb. info) ) 
return - ENODEV ; 
fb. notifier call chain( FB EVENT. FB. REGISTERED , &event) ; 
unlock, fb. info( fb, info) ; 


return 0; 





| 











这 些 接口 是 frame buffer 框架 和 具体 驱动 交互 的 桥梁 ， 通 过 它们 ， 设 备 驱 动 将 加 入 到 框 
架 中 供用 户 使 用 。 

从 整体 分 析 ，frame buffer 的 框架 很 直接 ， 主 要 就 是 直接 管理 实际 的 设备 ， 而 相关 的 操 
作 与 应 用 层 直 接 相 关 。 相 关 的 操作 逻辑 可 以 通过 应 用 层 的 操作 来 理解 。 
6.2.3 ” 帧 缓冲 应 用 层 操作 及 框架 适 配 


先 以 一 个 DM3730 的 简单 例子 来 了 解 应 用 层 如 何 操作 frame buffer 的 。 如 下 所 示 : 






































#include < stdio. h > 
#include < unistd. h > 
#include < stdlib. h > 
#include < errno. h > 
#include < sys/ioctl. h > 
#include < sys/stat. h > 
#include < sys/mman. h > 
#include < fentl. h > 
#include < string. h > 
#include < linux/fb. h > 
#include < linux/fb. h > 
#include < asm/ioctl. h > 
#include < asm/types. h > 


/ * IOCTL commands. * / 
#define OMAP_IO( num) .IO( O ,num) 


422 


//DM3730 特殊 的 等 待 垂直 同步 的 TO ,垂直 同步 代表 新 一 帧 数据 的 开始 ,通过 该 同步 








/表明 硬件 相关 操作 的 安全 

#define OMAPFB_WAITFORVSYNC OMAP_IO(57) 
// 使 用 VSYNC 进行 操作 

#define WAIT_FOR_VSYNC 1 

#define ITERATIONS 1000000000 


int fd; 
unsigned char * data; 
struct fb_var_screeninfo var; 


struct fb_fix_screeninfo fix ; 


nt 
qur 


// 刷 新 frame, fj buf. no 指定 是 第 几 个 buffer 
int show, frame( int buf. no) 


| 








unsigned char * buf; 

static int start; 

// 以 屏幕 十 六 分 之 一 的 宽度 刷 一 个 bar 

int width = var. yres >>4; / *1/16th of the screen height * / 
struct fb_var_screeninfo v; 

int i=0,j =0,ret 20; 

// 横 条 的 颜色 
char color =OxAA; 





memopy ( &v , &var ,sizeof( v) ) ; 
人 显示 内 容 的 y W 

v. yoffset = v. yres * buf_no; 
// 相 应 帧 的 起 始 地 址 


buf = data + v. yoffset * fix. line_length; 





/ * clear the frame * / 
/清空 整 帧 


memset( ( void * )buf,0 fix. line length * var. yres) ; 


/ * draw a horizontal bar on the frame * / 
// 画 一 个 水 平 条 ,start 表示 起 始 行 画 width 行 


for(i= start;i < start + width;i ++ ) | 





for( j =0;j < var. xres * var. bits_per_pixel/8 ;j ++ ) 


buf| i * fix. line, length +j] = color; 
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/ * pan to that frame * / 
// 通 知 驱动 更 新 下 一 帧 的 内 容 
ret =ioctl(fd,FBIOPAN_DISPLAY , &v) ; 
if( ret) | 
printf( "ioctl FBIOPAN, DISPLAY failed n" ) ; 


return ret; 





/ * move the position of the bar for the next frame * / 
/移动 横 条 ,如 果 到 底部 再 从 项 部 开始 


start = start +1; 


























if( start + width > var. yres ) 
start =0; 


return 0; 


// 移 动 颜色 横 条 的 操作 接口 


int movie( int num_buf, int wait_vsync ) 


| 


int buf no 20; 

int k 20, ret 20; 

// AX 

for(k =0;k « ITERATIONS;k ++ ) | 
/显示 横 条 
ret = show_frame(buf_no ; 
if( ret) 


return ret ; 


// 等 待 VSYNC 信和 号 
if( wait_vsync ) | 


ret = ioctl( fd, OMAPFB. WAITFORVSYNC,0) ; 





if( ret) | 
printf( " Xn ioctl OMAPFB_WAITFORVSYNC failed" ) ; 
return ret ; 


| 
// 表 示 应 该 操作 的 是 下 一 帧 的 buffer 


buf no = ( ++buf no)% num buf; 





| 


return 0 ; 


/初始 化 操作 


int init, fb( char * devname ) 


| 


int num buf = 1; 


int ret 20; 


/ ** Open framebuffer device * / 
// 打 开设 备 
fd = open( devname,O_RDWR) ; 
if(fd <=0) | 

printf( " Could not open device Wn" ) ; 





| 
// 获 得 固定 信息 
ret = ioctl (fd, FBIOGET. FSCREENINFO , &fix ) ; 
if( ret) | 
printf( "ioctl FBIOGET_FSCREENINFO failed Wn" ) ; 





return ret; 
| 
// 获 得 可 变 信息 
ret = ioctl ( fd, FBIOGET. VSCREENINFO , &var) ; 
if( ret) | 
printf( " ioctl FBIOGET_VSCREENINFO failed Wn" ) ; 





return ret ; 


// 映 射 整个 frame buffer 的 存储 空间 
data = (unsigned char * ) mmap(0, 
fix. line length * var. yres_virtual , 
(PROT READ | PROT. WRITE) , 
MAP SHARED ,fd,0) ; 
if( ! data) | 
printf( " mmap failed for %d x 96 d of % d\n", \ 
fix. line length ,var. yres. virtual , fix. smem len) ; 
return - ENOMEM ; 
| 
[计算 真正 buffer 能 存放 的 帧 数 并 返回 
num_buf = var. yres_virtual/var. yres ; 


return num_buf; 


int main(int argc ,char * argv[ | ) 
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int i=0,ret 20; 

int num buf; 

if( Vargv[ 1]) | 
printf( " /dev/fbN parameter missing Wn" ) ; 
return - ENODEV ; 

| 

// 初 始 化 

if( ( num, buf = init fb(argv[1])) <0) | 
printf( " Could not initialize dev % s\n" ,argv[ 1]) ; 
return — 1; 

} 

// 移 动 横 条 

ret = movie(num_buf, WAIT_FOR_VSYNC) ; 

close( fd) ; 


return ret; 


从 这 个 例子 基本 可 以 明确 应 用 是 如 何 使 用 frame buffer 的 ， 操 作 流 程 进 行 总 结 如 图 6-8 
所 示 。 
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图 6-8 应 用 对 frame buffer 的 操作 流程 
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Android 系统 中 ， 其 对 应 frame buffer 的 适 配 过 程 也 是 类 似 的 ， 由 于 系统 还 要 操作 如 3D 
加 速 的 Graphic 设备 ， 所 以 Android 将 二 者 归 为 gralloc 设备 ，frame buffer 作为 其 子 设 备 
存在 。 

Android 针对 frame buffer 的 适 配 操作 都 是 在 Framebuffer. cpp 中 实现 的 。 其 中 mapFrame- 
BufferLocked 负责 映射 空间 ， 相 关 代 码 如 下 : 





int err; 
size_t fbSize = roundUpToPageSize( finfo. line length * info. yres_virtual) ; 
module -> framebuffer = new private handle t( dup( fd) ,fbSize,0) ; 


module —> numBuffers = info. yres_virtual/info. yres; 


module -> bufferMask =0; 


void * vaddr = mmap (0 ,fbSize, PROT_READ | PROT. WRITE, MAP. SHARED ,fd,0) ; 
if( vaddr == MAP. FAILED) | 

ALOGE( " Error mapping the framebuffer( 96 s) " ,strerror( errno) ) ; 

return — errno; 

| 


module -> framebuffer -> base = intptr. t( vaddr) ; 
memset ( vaddr ,0 ,fbSize ) ; 


而 显示 切换 则 由 fb, post 实现 ， 相 关 代 码 如 下 : 





if(hnd —> flags & private handle t;;PRIV FLAGS FRAMEBUFFER ) | 
const size_t offset = hnd —» base — m —> framebuffer -> base; 
m —> info. activate = FB. ACTIVATE VBL; 
m —> info. yoffset = offset/m —> finfo. line, length; 
if( ioctl( m -> framebuffer — > fd, FBIOPAN. DISPLAY, &m -> info) == -1)| 
ALOGE( " FBIOPAN, DISPLAY failed" ) ; 
m —> base. unlock ( &m —> base, buffer) ; 


return — errno; 


#ifndef OMAP_FB 
if( ioctl (m —» framebuffer —> fd, FBIO WAITFORVSYNC,0)) | 
ALOGE("FBIO WAITFORVSYNC failed" ) ; 
m —> base. unlock ( &m —> base, buffer) ; 


return — errno; 
#else 
#define OMAP_IO( num) .IO( O ,num) 


#define OMAPFB_WAITFORVSYNC OMAP IO(57) 
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unsigned int dummy ; 
if( ioctl( m -> framebuffer — > fd, OMAPFB_WAITFORVSYNC, &dummy ) <0) | 
ALOGE("OMAPFB WAITFORGO failed" ) ; 


return 0; 
#endif 
Android 会 对 这 些 接口 通过 统一 的 封装 提供 给 应 用 层 从 而 完成 适 配 。 
6.2.4 TI 芯片 帧 缓冲 驱动 相关 实现 详解 


TI DM3730 的 frame buffer 驱动 针对 的 硬件 设备 是 display controller， 硬 件 框 图 如 图 6-9 
所 示 。 图 6-9 引 自 《DM3730 芯片 手册 》 中 第 1624 页 框图 。 
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Kl 6-9 DM3730 display 控制 器 硬件 框图 


从 图 6-9 可 见 ，DM3730 支持 3 个 不 同 的 显示 通道 ， 而 且 所 有 的 通道 都 通过 DMA 自动 
获得 显示 信息 进行 显示 ， 不 同 的 通道 可 以 以 一 定 顺 序 进行 到 加 ， 在 显示 硬件 上 也 可 以 有 两 个 
显示 设备 ， 硬 件 提 供 了 在 不 同 的 显示 通道 以 及 硬件 显示 设备 切换 的 能 

1. 整体 框架 

为 了 支持 硬件 的 各 种 功能 ， 在 相应 的 驱动 设计 过 程 中 杠 设计 了 DSS (display subsystem) 
架构 支持 该 功能 。 整 体 的 架构 如 图 6-10 所 示 。 
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图 6-10 DM3730 显示 子 系统 软件 整体 架构 


从 图 6-10 可 见 ， 在 驱动 框架 部 分 ，DSS 的 设计 支持 frame buffer 和 V4L2 两 种 架构 ， 这 
是 由 于 两 种 类 型 的 设备 都 是 通过 硬件 的 display 子 系统 进行 显示 ， 它 们 之 间 可 以 通过 个 加 子 
系统 进行 羡 加 ， 这 样 相当 于 在 硬件 层 进行 了 硬件 加 速 ， 可 以 实现 良好 的 显示 效果 。 

在 系统 设计 中 还 开放 了 sys 文件 系统 接口 ， 可 以 方便 地 进行 切换 和 设置 ， 来 满足 各 种 动 
态 的 需求 。 

DSS 系统 中 各 个 模块 与 硬件 的 对 应 关系 如 图 6-11 所 示 。 

从 图 6-11 PIL, 不 同 的 pipeline 是 由 overlay 进行 管理 来 表示 不 同 的 overlay 层 ， 而 man- 
ager 则 是 管理 硬件 的 徐 加 控制 以 及 之 后 的 显示 通路 ， 会 对 应 到 显示 接口 ，display 部 分 是 对 显 
示 接 口 的 控制 ，panel 则 是 对 应 真实 的 显示 设备 。 





























开放 的 sys 接口 如 下 : 
/sys/class/graphics/fb?: 控制 frame buffer 接 入 哪个 pipeline 即 逻 辑 的 overlay 层 
mirror 0 =off,1 =on 
rotate Rotation 0 —3 for 0,90 ,180,270 degrees 
overlays List of overlay numbers to which framebuffer pixels go 
phys_addr Physical address of the framebuffer 
virt_addr Virtual address of the framebuffer 
size Size of the framebuffer 





/sys/devices/platform/omapdss/overlay?: A AIRA AVA EE ES E BR 
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图 6-11 DSS 软件 模块 与 硬件 对 应 关系 图 





enabled 0 = off,1 =on 

input_size width ,height(ie. the framebuffer size) 

manager Destination overlay manager name 

name 

output_size width, height 

position x,y 

screen_width width 

global_alpha global alpha 0 -255 0 = transparent 255 = opaque 


/sys/ devices/platform/omapdss/manager? ; WAF ÆJ ZUI XZ Jes fib zs 88 PE EI t BE 
display Destination display name 

alpha. blending enabled 0 =off,1 =on 

trans_key_enabled 0 =off,1 = on 

trans_key_type gfx — destination , video — source 

trans_key_value transparency color key( RGB24) 

default_color default background color( RGB24 ) 








/sys/devices/platform/omapdss/ display? : 显示 接口 的 信息 和 设置 


ctrl_name Controller name 
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mirror 0 =off,1 = on 


update_mode 0 = off, 1 = auto,2 = manual 

enabled 0 =off,1 = on 

name 

rotate Rotation 0 —3 for 0,90,180,270 degrees 

Timings Display timings ( pixclock , xres/hfp/hbp/hsw , yres/ vfp/ vbp/ vsw ) 
tv — out; "pal" and "ntsc" 


panel name 


tear elim Tearing elimination 0 = off,1 = on 





WoW LWA RA CH ae, BER ZRH 
2. Frame Buffer 驱动 
接 下 来 看 看 frame buffer 驱动 是 如 何 实现 的 。TI frame buffer 驱动 的 核心 管理 实体 是 


omapfb2 device, 

















struct omapfb2. device | 
struct device * dev; 


struct mutex mtx; 


u32 pseudo. palette| 17 ] ; 


int state; 


unsigned num, fbs; 
struct fb. info * fbs[ 10] ; 


struct omapfb2, mem, region regions[ 10 ] ; 


unsigned num. displays; 

struct omap. dss, device * displays| 10] ; 
unsigned num, overlays ; 

struct omap. overlay * overlays[ 10 ] ; 
unsigned num managers ; 


struct omap. overlay, manager * managers| 10 ] ; 


unsigned num bpp. overrides ; 
struct | 
struct omap. dss. device * dssdev; 
u8 bpp; 
| bpp_overrides[ 10] ; 
E 





从 内 容 看 其 管理 了 上 层 也 _info 以 及 内 部 的 overlay, manager 还 有 display， 实 际 它 就 是 
display subsystem 的 逻辑 实体 。 
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相关 的 初始 化 是 在 platform 驱动 的 probe 中 进行 的 ， 具 体 分 析 如 下 : 


// 进 行 omapfb 的 驱动 与 device 绑 定 的 接口 ,主要 是 在 系统 初始 化 是 执行 


// 主 要 是 初始 化 驱动 管理 的 各 个 接口 ,并 创建 与 kernel 之 间 的 接口 frame 














static int omapfb_probe( struct platform_device * pdev) 


| 


struct omapfb2_device * fbdev = NULL; 
int r=0; 

int 1; 

struct omap_overlay * ovl ; 

struct omap_dss_device * def_display; 


struct omap_dss_device * dssdev; 


//omapfb driver 不 支持 对 于 mem irq, dma 等 resource 的 注册 
if( pdev -> num_resources !=0) | 
dev_err( &pdev -> dev," probed for an unknown device\n" ) ; 
r= - ENODEV; 
goto eri0 ; 


// 分 配 相应 driver 管理 结构 omapfb2, device 的 空间 
fbdev = kzalloc( sizeof( struct omapfb2_device) ,GFP_KERNEL) ; 
if(fbdev == NULL) | 

r= - ENOMEM; 





goto eri0 ; 


/ * TODO : Replace cpu check with omap. has vrfb once HAS FEATURE 


* available for OMAP2 and OMAP3 

*/ 

if( def. vrfb && ! cpu. is omap24xx( ) && ! cpu, is. omap34xx( ) ) | 
def vrfb 20; 


dev. warn( &pdev -> dev," VRFB is not supported on this hardware , " 


"ignoring the module parameter vrfb = y\n" ) ; 


mutex, init( &fbdev -> mtx) ; 





// Y omapfb2, device 加 入 到 kernel 的 Idm 的 device 的 私有 data 4 
fbdev -> dev = &pdev -> dev; 
platform, set. drvdata( pdev , fbdev ) ; 


il 


buffer 


// 由 于 还 没有 加 载 display ,所 以 先 做 初始 化 
r=0; 





fbdev -> num. displays =0; 

dssdev = NULL; 

// W) dss bus 获得 所 有 的 display 设备 

for_each_dss_dev( dssdev) | 
// 获 得 相应 的 Idm 的 device ,从 而 避免 device 被 release 从 而 被 remove ,由 于 
// for_each_dss_dev 中 也 会 通过 omap_dss_get_next_device 来 put 之 前 的 device 
omap_dss_get_device( dssdev ) ; 





























if( ! dssdev —> driver) | 
dev. err( &pdev -> dev," no driver for display Wn" ) ; 
r= - ENODEV; 


// 记 录 omapfb2. device 管理 的 所 有 display 
fbdev -> displays[ fbdev -> num, displays ++ | = dssdev; 








if(r) 


goto cleanup; 


if( fbdev -> num. displays 2-0) | 
dev. err( &pdev -> dev," no displays Wn" ) ; 
r= - EINVAL; 


goto cleanup; 


// 获 得 所 有 的 overlay 和 overlay. manager 
fbdev -> num_overlays = omap. dss. get. num, overlays( ) ; 
for(i =0;i < fbdev -> num overlays;i ++ ) 


fbdev -> overlays[ i] = omap. dss, get. overlay(i) ; 


fbdev -> num, managers = omap. dss get, num, overlay. managers( ) ; 





for(i =0;i < fbdev -> num managers;i ++ ) 


fbdev -> managers[ i] = omap_dss_get_overlay_manager(1) ; 


[解析 并 设置 相应 的 display mode 
if( def mode && strlen( def mode) » 0) | 
if( omapfb parse def modes(fbdev) ) 


dev. warn( &pdev -> dev," cannot parse default modes n" ) ; 
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// 创 建 kernel 的 frame buffer 接口 ,主要 是 分 配 显存 初始 化 了 b_info 等 
r = omapfb create. framebuffers ( fbdev ) ; 
if(r) 


goto cleanup; 





// 针 对 之 前 初始 化 的 结果 设置 dispe 在 dss2 框架 下 的 overlay manager 
// 的 配置 应 用 apply 操作 


for(i =0;1 < fbdev -> num managers;i ++ ) | 








struct omap_overlay_manager * mgr; 
mer = fbdev —» managers i | ; 
r = mgr —>apply( mer) ; 
if(r) 
dev. warn( fbdev -> dev," failed to apply dispe config Wn" ) ; 


/ * gfx overlay should be the default one. find a display 
* connected to that, and use it as default display * / 
// BRIT] overlay 4 graphic overlay ,获得 默认 的 显示 设置 gfx 
ovl = omap. dss, get, overlay (0) ; 
if( ovl -> manager && ovl -> manager -> device) | 
def display = ovl -> manager —» device; 
| else} 
dev. warn( &pdev -> dev," cannot find default display Wn" ) ; 
def display NULL; 


if( def. display) | 
// 有 默认 的 display 则 enable 


struct omap. dss driver * dssdrv = def. display -> driver; 


r = def display -> driver -> enable( def. display) ; 
if(r) | 
dev. warn( fbdev -> dev," Failed to enable display 965 Wn", 
def display -> name) ; 


goto cleanup; 























// 根 据 manual 或 者 auto update 方式 进行 必要 的 设置 
if( def. display -> caps & OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE) | 
ul6 w,h; 
if( dssdrv -> enable. te) 
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dssdrv -> enable, te( def. display,1) ; 
if( dssdrv —» set, update mode) 
dssdrv -> set. update mode( def display, OMAP. DS8 UPDATE MANUAL); 


dssdrv —> get, resolution( def. display , &w , &h) ; 
def display -> driver -> update( def. display ,0,0 , w,h) ; 
| else} 
if( dssdrv —» set_update_mode ) 
dssdrv -> set. update mode( def. display, OMAP. DSS UPDATE AUTO) ; 


DBG( " create sysfs for fbs\n" ) ; 

// 创 建 sysfs 为 设置 开放 相应 的 接口 
r = omapfb_create_sysfs(fbdev) ; 

if(r) | 


dev. err( fbdev -> dev," failed to create sysfs entries\n" ) ; 





goto cleanup ; 


return 0; 


cleanup: 
omapfb_free_resources ( fbdev ) ; 
en: 
dev. err( &pdev -> dev," failed to setup omapfb n" ) ; 


return r; 





通过 以 上 初始 化 后 ， 就 可 以 通过 sys 文件 系统 对 相关 属性 进行 设置 了 。 另 外 frame buffer 
的 可 变 参数 也 是 可 以 修改 的 (如 FBIOPAN_DISPLAY 命令 ) 。 驱 动 应 对 这 种 修改 通过 mapfb_ 
apply changes 来 实现 。 具 体 分 析 如 下 : 


























//omap 设置 对 frame buffer 的 overlay 的 修改 。 该 孔 数 会 在 标准 的 fram buffer ioctl 
//omap 特殊 的 ioctl 以 及 sysfs 等 需要 进行 frame buffer 到 overlay 切换 的 场景 调用 











int omapfb_apply_changes( struct fb, info * fbi, int init) 
| 
int r=0; 
struct omapfb, info * ofbi = FB2OFB (fbi) ; 
struct fb_var_screeninfo * var = &fbi — > var; 
struct omap. overlay * ovl; 


ul6 posx, posy ; 
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ul6 outw,outh; 


int 1; 


#ifdef DEBUG 
if( omapfb_test_pattern ) 
fill_fb( fbi) ; 
#endif 
WARN. ON( ! atomic_read( &ofbi — > region — > lock, count) ) ; 


//Xj frame buffer 绑 定 的 overlay 都 进行 设置 
for(i=0;i<ofbi->num overlays;i++ )| 


ovl = ofbi -> overlays[ i] ; 


if( ofbi —» region —> size 2-0) | 
/ ** the fb is not available. disable the overlay * / 
// 对 于 没有 分 配 frame buffer [fJ , disable overlay 
omapfb. overlay. enable( ovl,0) ; 
if( Finit && ovl -> manager) 
ovl -> manager -> apply( ovl -> manager) ; 


continue ; 


// 根 据 overlay 的 属性 设置 输出 的 分 辩 率 
if( init || (ovl -> caps & OMAP_DSS_OVL_CAP_SCALE) ==0) | 
// 根 据 旋 转 情 况 设置 输出 分 辩 率 
int rotation = ( var —> rotate + ofbi —> rotation| i] ) 96 4; 
if( rotation == FB_ROTATE_CW || 
rotation == FB_ROTATE_CCW) } 


outw = var —> yres; 





























outh = var 一 > xres; 

| else} 
outw = var —> xres; 
outh = var —> yres; 

} 

| else} 
// 如 果 overlay 支持 scale 则 设置 缩放 的 分 辩 率 
outw = ovl —> info. out_width; 


outh = ovl -> info. out, height ; 


// 设 置 显示 的 起 始 位 置 
if( init) | 
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posx =0; 
posy =0; 
| else} 
posx = ovl —> info. pos_x; 


posy = ovl -> info. pos. y; 


// TE fb. info 和 显示 参数 设置 overlay 
r = omapfb, setup. overlay ( fbi, ovl , posx , posy , outw , outh ) ; 


if(r) 


goto err; 























// apply overlay 的 设置 ,通过 manager 显示 ,这 里 会 调用 go. 1ed 来 刷新 shadow 寄存 器 
if( Finit && ovl -> manager) 











ovl —> manager -> apply ( ovl -> manager) ; 
} 
return 0; 
em; 
DBG( " apply. changes failed Wn" ) ; 
return r; 


| 


frame buffer 的 驱动 还 不 有 重要 的 内 容 就 是 对 显示 存储 空 间 的 2 分 配 和 映射 ， 下 面 进 行 相关 
的 分 析 。 
显示 存储 空间 的 分 配 系统 会 在 初始 化 的 时 候 通 过 启动 参数 预 留 ， 相 关 代 码 分 析 如 下 : 



































// 用 于 设置 bootargs 中 的 vram 设置 
static int __init omap_vram_early_vram( char * p) 


| 





omap. vram. def sdram, size = memparse( p, &p) ; 
if( 2s p zc 由 ) 
omap_vram_def_sdram_start = simple strtoul( p +1,&p,16) ; 


return 0; 


| 


early_param("vram" ,omap_vram_early_vram ; 


J * 
* Called from map_io. We need to call to this early enough so that we 
* can reserve the fixed SDRAM regions before VM could get hold of them. 
* / 
// 该 函数 会 在 machine, desc HY reserve 接口 调用 ,尽早 的 调用 以 保留 相应 的 连续 的 memory 
// 空 间 , 所 以 需要 在 VM 管理 相应 的 空间 之 前 调用 
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void __init omap_vram_reserve_sdram_memblock ( void ) 


| 





u32 paddr; 
u32 size =0; 


/ * cmdline arg overrides the board file definition * / 
// bootargs 的 配置 优先 级 要 高 , 先 用 bootargs 中 的 vram 设置 


if( omap_vram_def_sdram_size) | 





size = omap_vram_def_sdram_size ; 


paddr = omap. vram, def sdram, start; 


if( ! size) | 
// 如 果 bootargs 中 没有 设置 vram, 则 用 board 修改 


size = omap_vram_sdram_size; 






































paddr = omap_vram_sdram_start; 


#ifdef CONFIG_OMAP2_VRAM_SIZE 























if( | size) | 
/没有 设置 的 话 则 用 默认 的 设置 
// KU 4M 
size = CONFIG_OMAP2_VRAM_SIZE * 1024 * 1024 ; 
paddr =0; 

| 

#endif 

if( ! size) 
return; 

//size 为 2M 对 齐 


size = ALIGN( size, SZ 2M); 


if( paddr) | 
// 如 果 指 定 起 始 地 址 则 进行 检查 
// 页 对 齐 检查 
if( paddr & ~ PAGE_MASK) | 
pr_err(" VRAM start address Ox% 08x not page aligned\n" , 
paddr) ; 


return ; 
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// 地 址 范围 是 否 在 kernel 管理 的 region 中 
if( ! memblock_is_region_memory( paddr,size) ) | 
pr_err( "lllegal SDRAM region 0x% 08x. . 0x% 08x for VRAM\n" , 
paddr, paddr + size - 1) ; 








return; 


OZ reserve 
if . Scrat Seen paddr, size) ) | 
pr_err( "FB; failed to reserve VRAM - busy\n" ) ; 


return ; 


//veserve 相应 的 空间 

if( memblock_reserve( paddr, size) <0) | 
pr err( " FB; failed to reserve VRAM -no memory n" ) ; 
return; 

} 

else} 

// 没 有 指定 起 始 地 址 , 则 直接 分 配 相应 大 小 空间 

//2M 对 章 ,返回 分 配 的 起 始 地 址 

paddr = memblock_alloc( size ,SZ_2M) ; 


// 将 相应 的 空间 从 kernel 管理 的 memory block 中 移 除 
memblock_free(paddr,size) ; 





memblock_remove(paddr,size) ; 


1È 


// 相 应 的 空间 由 vram 管理 


omap. vram add region( paddr, size) ; 





pr. info( " Reserving 96u bytes SDRAM for VRAM Wn" ,size) ; 
} 





S 








存 的 空间 通过 vram 统一 管理 ， 这 部 分 空间 不 在 内 核 的 管理 范围 内 ， 相 应 的 分 配 也 是 
由 vram 的 分 配 函 数 omap__vram_alloc 来 进行 ， 具 体 的 分 配 工 作 则 是 在 驱动 probe 中 通过 
omapfb_create_framebuffers 来 执行 的 。 

驱动 也 提供 了 相应 的 映射 接口 omapfb | mmap， 分 析 如 下 : 





























//frame buffer 设备 驱动 的 mmap 接口 函数 
static int omapfb_mmap(struct fb_info * fbi, struct vm. area, struct * vma) 


| 
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struct omapfb_info * ofbi = FB2OFB (fbi) ; 
struct fb_var_screeninfo * var = &fbi 一 > var; 
struct fb_fix_screeninfo * fix = &fbi —> fix; 
struct omapfb2 mem region * rg; 

unsigned long off; 

unsigned long start; 

u32 len; 

int r= — EINVAL; 


// X] vm. area 的 区 域 进行 检查 

if( vma -> vm, end - vma —> vm, start ==0) 
return 0; 

if( vma -> vm, pgoff > ( ~ OUL >> PAGE SHIFT) ) 
return — EINVAL; 

off = vma —» vm_pgoff << PAGE SHIFT; 


/A/ 锁 保护 

rg = omapfb_get_mem_region( ofbi —> region) ; 
// 获 得 相应 omapfb 管理 的 物理 区 域 的 物理 起 始 地 址 
start = omapfb_get_region_paddr( ofbi, var —> rotate) ; 
//memory 的 大 小 


len = fix -> smem len; 


// 进 行 虚拟 空间 vm. area 和 物理 分 配 显存 空间 的 容量 检 
// 不 应 该 超出 frame ”buffer 管理 的 memory 空间 
if( off >= len) 


goto error; 








if( ( vma —» vm. end - vma —> vm, start + off) > len) 


goto error; 
off + = start; 


// VEE. vm. area 相关 参数 

vma — > vm. pgoff = off >> PAGE SHIFT; 

vma -> vm, flags |= VM_IO | VM. RESERVED; 

// 见 ARM MMU cache and buffer WHH ,这 里 设置 buffered 数据 
vma —» vm. page. prot = pgprot_writecombine( vma -> vm. page. prot) ; 
// 设 置 vm, ops 操作 接口 

vma —» vm. ops = &mmap, user ops; 

// 设 置 操作 接口 需要 的 特定 private, data 


vma — > vm_private_data = rg; 
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// 进 行 实际 的 物理 地 址 的 映射 
if(io_remap_pfn_range( vma , vma -> vm_start, off >> PAGE_SHIFT, 
vma —» vm, end — vma —> vm, start , 
vma —» vm, page. prot) ) | 
r= —EAGAIN; 


goto error; 


/ * vm, ops. open won t be called for mmap itself. * / 
// 增 加 计数 ,由 于 mmap 本 身 不 会 调用 vm. ops. open, 这 里 实际 
//region 已 经 使 用 所 以 主动 增加 计数 


atomic_inc( &rg ->map_count ) ; 




















omapfb_put_mem_region( rg) ; 


return 0; 


error: 


omapfb. put, mem, region( ofbi -> region) ; 


return r; 


| 








从 分 析 中 可 见 ， 设 置 了 虚拟 地 址 区 域 的 操作 接口 mmap_user_ops， 由 于 相应 的 映射 是 通 
过 io_remap_pfn_range 的 整体 映射 ， 并 不 需要 进行 缺 页 异常 的 操作 ， 所 以 mmap_user_ops 只 
提供 了 open 和 release 的 接口 用 于 引用 计数 的 操作 。 

用 户 对 frame buffer 的 操作 基本 都 通过 以 上 的 功能 完成 。 

3. 显示 设备 的 管理 

从 DSS 硬件 可 见 ， 其 可 以 文 持 多 个 显示 设备 ， 这 有 些 类 似 于 总 线 ， 为 了 能 够 同时 文 持 
多 个 显示 设备 ， 驱 动 设计 并 实现 了 一 种 逻辑 总 线 dss_bus。 相 关 分 析 如 下 : 















































//bus 类 型 ,会 注册 到 kernel 中 的 bus 
static struct bus, type dss_bus_type = | 
. name =" omapdss" , 
. match = dss. bus, match, 
. dev. attrs = default, dev. attrs,, 


. drv_attrs = default, drv. attrs, 


E 


// 设 备 和 驱动 进行 match 的 接口 函数 
static int dss_bus_match( struct device * dev ,struct device_driver * driver ) 


| 
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struct omap_dss_device * dssdev = to_dss_device( dev) ; 


DSSDBG( " bus, match. dev 96 s/96 s,drv % s\n", 


dev. name( dev) ,dssdev -> driver. name, driver -> name) ; 





// 通 过 name 进行 匹配 


return stremp( dssdev —> driver. name ,driver - > name) ==0; 


另外 在 设备 与 驱动 绑 定 需要 相应 的 注册 接口 ， 具 体 的 分 析 如 下 : 





T 





//dss bus 注册 device 的 接口 函数 ,目前 只 有 使 用 omap. dss. probe 来 注册 board 文件 
// 声 明 的 所 有 dss_device 
int omap_dss_register_device( struct omap_dss_device * dssdev ) 


| 





static int dev_num; 


//clear device 的 数据 

reset, device( &dssdev -> dev ,1 ) ; 

// 设 置 默 认 的 bus 和 parent device 

dssdev -> dev. bus = &dss_bus_type; 

dssdev -> dev. parent = &dss bus; 

dssdev -> dev. release = omap. dss. dev. release; 

// 设 置 name 

dev_set_name( &dssdev -> dev," display% d" ,dev_num ++ ) ; 
// 调 用 ldm 的 device 注册 接口 


return device, register( &dssdev —> dev) ; 


//dss bus 注册 drvier 
int omap_dss_register_driver( struct omap_dss_driver * dssdriver ) 


| 








// 首 先 注册 总 线 级 别 的 操作 和 bus. type 


dssdriver —> driver. bus = &dss_bus_type; 








dssdriver —> driver. probe = dss_driver_probe; 


dssdriver —> driver. remove = dss_driver_remove; 


if( dssdriver -> get_resolution == NULL) 

dssdriver —> get_resolution = omapdss_default_get_resolution ; 
if( dssdriver -> get_recommended_bpp == NULL) 

dssdriver — > get_recommended_bpp = 


omapdss_default_get_recommended_bpp; 
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// 调 用 ldm 的 driver 注册 接口 ,由 于 bus 默认 会 自动 匹配 所 以 会 进行 match 操作 
// 进 而 执行 bus 级 别 的 probe 即 dss_driver_probe 


return driver_register( &dssdriver —> driver) ; 





| 


HJ UL dss bus 管理 的 实体 就 是 设备 omap_dss_device 和 驱动 omap_dss_driver， 在 omap_dss 
_device 中 主要 是 显示 设备 的 硬件 信号 信息 ， 而 omap_dss_driver 则 是 操作 接口 (包括 功能 
电源 管理 操作 ) 。 

如 果 整 个 dss 编 进 内 核 的 话 ， 相 应 的 初始 化 如 下 : 


























static int __init omap_dss_init( void) 


| 


return omap_dss_bus_register( ) ; 


static int __init omap_dss_init2 ( void) 


return platform_driver_register( &omap. dss driver) ; 


core, initcall( omap_dss_init) ; 


device, initcall( omap_dss_init2) ; 


可 见 bus 的 初始 化 要 早 于 相应 的 驱动 ， 这 样 就 在 dss 驱动 初始 化 probe 的 过 程 中 将 所 有 
的 显示 设备 信息 注册 ， 而 驱动 注册 的 时 候 就 可 以 将 二 者 绑 定 。 

这 样 就 完成 了 多 种 显示 设备 的 管理 ， 从 而 可 以 实现 各 种 复杂 的 功能 。 
6.2.5 帧 缓冲 驱动 电源 管理 相关 说 明 


通常 显示 设备 的 电源 管理 功能 就 是 通过 blank 接口 实现 的 ， 先 来 看 看 frame buffer 提供 的 
标准 接口 的 实现 



























































int fb. blank( struct fb, info * info ,int blank) 


| 
int ret = — EINVAL; 


if( blank > FB_BLANK_POWERDOWN) 
blank = FB. BLANK POWERDOWN; 


if( info —» fbops -> fb. blank) 
ret = info —> fbops —» fb. blank( blank , info) ; 
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if( ! ret) | 


struct fb. event event; 


event. info = info; 
event. data = &blank ; 
fb. notifier call chain( FB. EVENT BLANK, &event) ; 


return ret ; 


其 中 直接 调用 了 frame buffer 驱动 的 blank 接口 ， 接 下 来 是 DM3730 的 驱动 实现 : 








//blank display 的 接口 ,主要 用 作 blank/unblank 显示 display 
static int omapfb_blank (int blank ,struct fb_info * fbi) 


| 




















// 首 先 要 获得 display 的 属性 信息 
struct omapfb, info * ofbi = FB2OFB(fbi) ; 
struct omapfb2. device * fbdev = ofbi -> fbdev; 








struct omap. dss, device * display = fb2 display ( fbi) ; 
int do update 20; 


int r=0; 


if( ! display ) 
return — EINVAL; 


omapfb_lock (fbdev) ; 


switch( blank) | 
case FB BLANK. UNBLANK : 
//ublank 则 display 的 状态 应 该 是 suspend 
if( display -> state != OMAP_DSS_DISPLAY_SUSPENDED) 


goto exit; 


// 调 用 display 的 resume 接口 恢复 
if( display -> driver -> resume) 


r = display -> driver — > resume ( display ) ; 
// € display 在 resume 需要 手动 update 用 以 恢复 ， 
// XX FER] display panel 驱动 会 将 update mode 设 为 


//OMAP. DSS UPDATE, MANUAL ,这 里 置 标识 ,后 面 update 
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if(r 220 && display -> driver -> get. update mode && 
display -> driver -> get, update mode( display) == 
OMAP DSS UPDATE MANUAL) 
do. update 21; 


break ; 


case FB. BLANK, NORMAL: 

/ * FB BLANK, NORMAL could be implemented. 

* Needs DSS additions. * / 

case FB. BLANK. VSYNC SUSPEND: 
case FB. BLANK HSYNC SUSPEND: 
case FB. BLANK POWERDOWN: 

// 其 他 属于 blank 操作 ,检查 状态 应 为 active 

if( display -> state !- OMAP DSS DISPLAY ACTIVE) 


goto exit; 








i 


// 进 行 suspend 操作 
if( display -> driver -> suspend) 
r = display -> driver -> suspend( display ) ; 


break ; 


default; 
r= - EINVAL; 
exit; 
omapfb_unlock( fbdev) ; 
// F5] update 需要 进行 操作 
if(r 220 && do update && display -> driver -> update) | 
ul6 w,h; 


display — > driver -> get. resolution( display ,&w, &h ) ; 


r = display —> driver —> update( display ,0,0 , w,h) ; 


return r; 


可 见 会 找到 所 有 frame buffer 相对 应 的 omap. dss, device HI display， 然 后 对 display 做 正确 
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的 操作 。 





以 上 是 单个 显示 设备 的 电源 管理 工作 ， 而 当 整 个 系统 进入 待机 状态 时 要 对 所 有 的 
备 进 行 相关 的 操作 。 这 些 操作 是 通过 platform driver omap_dss_driver 来 实现 的 。 




















static struct platform_driver omap_dss_driver = | 


| 


. probe =omap_dss_probe, 
. remove = omap_dss_remove, 
. shutdown = omap. dss shutdown, 
. suspend = omap. dss suspend, 
. resume = omap dss resume, 
. driver = | 

. Name ="omapdss" , 

. owner = THIS MODULE, 


E 


具体 看 一 下 suspend 操作 : 


//suspend 操作 接口 


static int omap_dss_suspend( struct platform, device * pdev, pm. message t state ) 


| 


// Wei dss bus 的 所 有 设备 进行 suspend 操作 


return dss_suspend_all_devices( ) ; 





Ed 











M 





示 设 


HES suspend 所 有 的 device ， 具 体 通 过 dss_suspend_device 对 每 个 display 进行 suspend 
操作 ， 细 节 如 下 : 





// 将 display device suspend 


static int dss suspend device( struct device * dev , void * data) 


| 
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int r; 


struct omap_dss_device * dssdev = to_dss_device( dev) ; 


// 如 果 不 是 active 状态 , 则 需要 标记 ,resume 时 不 应 该 恢复 
if( dssdev — > state !=OMAP_DSS_DISPLAY_ACTIVE) | 


dssdev —> activate_after_resume = false; 





return 0; 


if( ! dssdev —> driver —» suspend) | 
DSSERR(" display 96$ doesn t implement suspend n" , 


dssdev -> name) ; 


return — ENOSYS; 
| 


// 调 用 display device driver 的 suspend 
r = dssdev -> driver —» suspend( dssdev) ; 
if(r) 


return r; 


// 设 置 resume 后 需要 恢复 的 状态 


dssdev —> activate_after_resume = true; 


return 0; 


| 
这 样 就 实现 了 单个 设备 级 别 以 及 整个 系统 级 别 在 frame buffer 层面 的 电源 管理 功能 。 
6.3 音频 设备 (audio ALSA) 


6.3.1 音频 设备 需求 


对 计算 机 以 及 藤 入 式 设备 来 说 ， 音 频 设备 同样 是 一 种 重要 的 输出 设备 ， 由 于 人 们 对 声音 
是 十 分 敏感 的 ， 所 以 在 有 人 机 交互 功能 的 设备 中 音频 设备 的 重要 性 就 不 言 而 喻 了 。 

声音 是 连续 的 模拟 信号 ， 而 音频 设备 是 要 将 这 些 模拟 信号 与 数字 信号 进行 转换 ， 从 而 满 
足音 频 的 输入 输出 的 需求 。 而 这 种 模拟 信号 和 数字 信号 转换 的 原理 如 图 6-12 所 示 。 
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图 6-12 音频 信号 模 数 转换 的 原理 
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从 图 6-11 可 见 这 种 转换 的 基本 原理 就 是 通过 离散 时 间 对 信号 进行 量化 来 实现 对 连续 模 
拟 信 号 尽量 准确 地 模拟 。 根 据 这 个 原理 可 知 对 音频 信号 数字 效果 的 影响 因素 如 下 : 
e 采样 频率 。 采 样 频率 是 指 单位 时 间 内 的 采样 次 数 。 采 样 频率 越 大 ， 采样 点 之 间 的 间隔 
就 越 小 ， 数 字 化 后 得 到 的 声音 就 越 表 真 ， 但 相应 的 数据 量 就 武大 。 声 音 采 样 频率 以 
kHz (TAE) 衡量 。 
e 量化 位 数 (采样 位 数 ) 。 量 化 位 数 是 模拟 量 转换 成 数字 量 之 后 的 数据 位 数 。 量 化 位 数 
表示 的 是 声音 的 振幅 ， 位 数 越 多 ， 音 质 越 细腻 ， 相 应 的 数据 量 就 越 大 。 量 化 位 数 主要 
有 8 位 和 16 位 两 种 。 
e 声 道 数 。 声 道 数 是 指 处 理 的 声音 是 单 声 道 还 是 立体 声 。 单 声 道 在 声音 处 理 过 程 中 只 
单数 据 流 ， 而 立体 声 则 需要 左 、 右 声 道 的 两 个 数据 流 。 显 然 ,立体声 的 效果 要 好 ， 但 
相应 的 数据 量 要 比 单 声 道 的 数据 量 加 倍 。 
不 同 的 音频 效果 就 是 以 上 因素 的 各 种 组 合 ， 而 音频 设备 与 主 处 理 器 之 间 的 实际 音频 流 就 
是 通过 以 上 因素 获得 的 数字 音频 信息 。 所 以 驱动 要 能 够 支持 各 种 组 合 的 音频 信号 ， 其 中 必然 
包含 数据 流 的 传输 支持 以 及 控制 支持 。 另 外 音频 通常 包括 输入 和 输出 ， 输 入 和 输出 是 允许 同 
时 进行 的 ， 所 以 还 要 能 够 支持 音频 流 输入 输出 的 同时 传送 。 
另外 还 有 很 多 产生 和 制作 数字 音频 的 技术 (如 Sequencer, MIDI), ， 也 是 需要 与 音频 设 
备 进行 相应 的 支持 ， 这 属于 可 选 功能 。 

除了 以 上 数字 音频 的 部 分 (与 主 处理 器 关联 的 都 是 数字 信和 叶 ) ， 音 频 设备 还 有 模拟 部 
分 ， 这 部 分 对 于 驱动 的 需求 通常 是 在 控制 上 ， 数 据 流 都 是 转换 成 数字 信号 进行 存储 。 这 样 在 
需求 上 就 需要 分 为 控制 部 分 和 数据 部 分 ， 驱 动 也 要 对 这 些 进行 支持 。 

音频 设备 还 有 可 能 有 多 路 数据 源 ， 而 在 设备 内 部 作 混 音 ， 所 以 在 考虑 控制 需求 的 时 候 ， 

同样 要 考虑 相关 的 应 用 以 及 混 音 通路 的 设置 。 这 样 更 进一步 要 求 控 制 流 能 够 和 数据 流 分 离 。 
然而 控制 流 和 数据 流 不 仅 要 考虑 分 离 又 要 考虑 关联 ， 毕 竞 控 制 部 分 同样 需要 能 够 获取 数据 流 
格式 等 相关 的 信息 。 

总 体 来 说 ， 音 频 设备 可 理解 为 有 单一 控制 通路 ， 有 一 个 或 多 个 数据 通路 的 设备 。 


6.3.2. 音频 驱动 框架 解析 


目前 Linux 内 核 的 音频 框架 采用 ALSA (Advance Linux Sound Architecture) 架构 ， 该 架 
构 的 设计 充分 考虑 了 以 上 各 种 需求 。ALSA 整体 框架 如 图 6-13 所 示 。 

从 图 6-13 可 见 ALSA 不 仅 包 括 驱 动 部 分 ， 还 包括 应 用 层 的 库 。 应 用 层 的 库 主要 是 对 驱 
动 提 供 的 服务 进行 封装 ， 可 以 避免 应 用 程序 直接 进行 一 些 繁杂 的 ioctl 调用 ， 通 过 库 的 封装 
可 以 使 得 调用 流程 更 易于 理解 ， 从 而 整体 更 易于 应 用 程序 的 开发 。 

1. 整体 设备 管理 

这 里 主要 对 于 ALSA 架构 的 驱动 部 分 进行 解析 。 首 先 从 整个 框架 上 看 ，ALSA 可 以 分 为 
control, pem, midi, sequencer 等 几 个 部 分 ， 对 这 些 部 分 通常 是 通过 多 个 设备 文件 来 实现 应 
用 与 内 核 交 互 的 。 框 架 层 是 如 何 对 设备 文件 进行 划分 的 呢 9 这 一 点 可 以 通过 子 设备 号 的 划分 
来 了 解 。ALSA 提供 子 设备 号 的 静态 分 配 和 动态 分 配 两 种 方式 。 通 过 静态 分 配 更 容易 了 解 各 
个 设备 文件 的 特点 。 下 面 来 看 看 相关 代码 : 
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static int snd. kernel minor( int type, struct snd. card * card ,int dev) 


int minor; 


switch( type) | 
case SNDRV. DEVICE TYPE SEQUENCER : 
case SNDRV. DEVICE TYPE TIMER: 
minor = type; 
break ; 
case SNDRV_DEVICE_TYPE_CONTROL; 
if( snd. BUG, ON( ! card) ) 
return — EINVAL; 
minor = SNDRV. MINOR( card -> number, type) ; 
break ; 
case SNDRV_DEVICE_TYPE_HWDEP: 
case SNDRV. DEVICE TYPE RAWMIDI: 
case SNDRV. DEVICE TYPE PCM PLAYBACK: 
case SNDRV. DEVICE TYPE PCM CAPTURE: 
if( snd. BUG, ON( ! card) ) 
return — EINVAL; 
minor = SNDRV_MINOR( card -> number, type + dev) ; 
break ; 
default : 
return — EINVAL; 
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if( snd. BUG. ON( minor <0 || minor >=SNDRV_OS_MINORS) ) 
return — EINVAL; 


return minor; 


| 





从 代码 中 可 以 了 解 不 同 的 设备 类 型 以 及 设备 特点 。 从 分 类 的 角度 ， 音 频 设备 中 可 以 包括 
的 类 型 有 SEQUENCER, TIMER, CONTROL, HWDEP, RAWMIDI, PCM_PLAYBACK 以 及 
PCM_CAPTURE。 从 代码 可 见 ， 除 了 SEQUENCER 和 TIMER 之 外 ， 都 是 和 snd_card 相关 联 
的 。 这 是 由 于 SEQUENCER 和 TIMER 要 用 于 系统 级 的 音频 设备 ，SEQUENCER 允许 使 用 系 
统 中 所 有 的 MIDI 设备 ， 而 TIMER 是 允许 获得 系统 中 所 有 音频 设备 中 的 timer， 自 然 是 系统 
级 的 设备 ， 就 不 需要 与 card 进行 关联 。 而 其 他 类 型 的 设备 都 是 与 snd_card 有 关联 的 ， 其 中 
CONTROL 每 个 snd_card 只 能 有 一 个 ， 其 他 的 设备 则 是 允许 有 多 个 。 这 种 数量 的 关系 一 定 要 
明确 。 

对 众多 的 音频 设备 来 说 ，CONTROL 、PCM_PLAYBACK 和 PCM_CAPTURE 是 一 定 要 存在 
的 ， 其 他 的 设备 根据 具体 情况 可 有 可 无 。 所 以 后 续 主 要 以 CONTROL, 、PCM_PLAYBACK 和 
PCM_CAPTURE 进行 分 析 。 

从 以 上 部 分 可 见 ，ALSA 对 设备 管理 是 有 层次 的 ,组织 上 snd_card 是 设备 的 容器 ， 同 时 
也 是 设备 的 组 织 者 与 管理 者 ， 人 逻辑 上 snd_card 是 与 硬件 声卡 关联 。 声 卡 硬件 本 身 包含 不 同 
功能 的 硬件 模块 ， 这 些 不 同 的 模块 逻辑 上 也 是 设备 ， 所 以 软件 的 这 种 组 织 与 硬件 上 的 逻辑 组 
织 形 式 是 一 致 的 。 对 驱动 来 说 ， 需 要 实现 的 是 整个 声卡 的 驱动 ， 这 样 在 组 织 上 要 以 card 为 
核心 ， 驱 动 中 功能 性 的 操作 则 要 能 够 深入 到 具体 对 应 的 子 模块 。 

要 了 解 ALSA 如 何 组 织 这 些 不 同 层次 的 设备 ， 先 来 看 看 snd_card 的 内 容 : 



















































































struct snd_card | 


// 表 示 系 统 中 的 card 号 ,每 个 card 唯一 























int number; / * number of soundcard( index to snd_cards) * / 
// 方 便 理解 的 各 种 名 字 

char id[ 16] ; / * id string of this card * / 

char driver| 16] ; / * driver name * / 

char shortname| 32 ] ; / * short name of this soundcard * / 

char longname|[ 80 | ; / * name of this soundcard * / 

char mixername| 80 ] ; / * mixer name * / 

char components[ 128 | ; / * card components delimited with space * / 
struct module * module; / * top — level module * / 

// 用 于 实例 化 指向 具体 的 管理 实体 
































void * private_data; / * private data for soundcard * / 
void( * private free) ( struct snd_card * card); — / * callback for freeing of private data * / 
// 这 里 是 card 包含 的 具体 设备 列表 ,通过 链表 连接 起 来 


struct list_head devices ; / * devices * / 
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unsigned int last_numid; / * last used numeric ID * / 








struct rw_semaphore controls_rwsem; / * controls list lock * / 

rwlock, t ctl. files rwlock ; / * ctl files list lock * / 

// 控 制 接口 ,整个 card 统一 的 控制 接口 

int controls_count; / * count of all controls * / 

int user_ctl_count; / * count of all user controls * / 
struct list_head controls; / * all controls for this card * / 
struct list_head ctl_files; / * active control files * / 

// proc 相关 的 接口 

struct snd_info_entry * proc_root; / * root for soundcard specific files * / 
struct snd_info_entry * proc_id; / * the card id * / 

struct proc, dir entry * proc, root, link ; / * number link to real id * / 


/关联 到 该 card 上 所 有 打开 的 文件 ,设备 特殊 情况 下 需要 对 文件 进行 一 定 操作 





struct list_head files_list; / * all files associated to this card * / 
struct snd_shutdown_f_ops * s_f_ops; / * file operations in the shutdown state * / 
spinlock t files lock ; / * lock the files for this card * / 

int shutdown; / * this card is going down * / 

int free on, last, close ; / ** free in context of file release * / 


wait queue head t shutdown, sleep; 


// 这 里 指向 该 card 在 设备 模型 中 的 parent 设备 




















struct device * dev; / * device assigned to this card * / 
// 设 备 模型 中 card 的 设备 实体 
struct device * card_dev; / * cardX object for sysfs * / 


#ifdef CONFIG_PM 


// 电 源 管理 相关 部 分 
unsigned int power_state; / * power state * / 
struct mutex power. lock; / * power lock * / 


wait queue head t power. sleep; 
#endif 
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从 sud. card 的 整体 分 析 可 见 ， 其 主要 负责 整体 的 功能 以 及 设备 的 组 织 。 对 于 整体 功能 
主要 是 控制 功能 以 及 整体 的 电源 管理 方面 ; 在 设备 组 织 方面 ， 是 通过 devices 链表 来 对 所 有 
的 子 设备 进行 管理 ， 子 设备 的 类 型 就 是 之 前 介绍 的 各 种 类 型 。 为 了 方便 管理 ，ALSA 将 各 种 
类 型 的 子 设备 统一 抽象 出 snd_device， 用 于 card 对 子 设备 进行 管理 ， 细 节 如 下 : 





























struct snd_device| 


// 进 行 设备 连接 





451 


struct list_head list; / * list of registered devices * / 








// 关 联 的 card 实体 

struct snd_card * card; / * card which holds this device * / 
// 设 备 所 处 的 状态 与 设备 是 否 注册 ,还 是 只 加 入 到 card 进行 管理 
snd_device_state_t state; / * state of the device * / 
设备 类 型 

snd_device_type_t type; / * device type * / 

/设备 的 实例 化 信息 ,各 种 类 型 设备 不 同 

void * device_data; / * device structure * / 

// 实 例 化 的 操作 

struct snd_device_ops * ops; / * operations * / 


E 


可 见 主要 进行 不 同类 型 子 设 备 实例 化 的 部 分 就 是 type, device_data 以 及 ops。 其 中 snd_ 
device, ops 的 定义 如 下 : 








struct snd_device_ops | 
int( * dev_free) (struct snd_device * dev) ; 
int( * dev, register) ( struct snd_device * dev) ; 


int( * dev. disconnect) (struct snd. device * dev) ; 
E 


主要 是 操作 接口 ， 这 样 可 以 将 操作 与 属性 完全 隔离 ， 方 便 后 续 扩展 。 
系统 还 提供 统一 实例 化 各 种 类 型 设备 的 接口 snd_device_new， 内 容 如 下 : 














int snd_device_new( struct snd_card * card ,snd_device_type_t type, 


void * device_data, struct snd_device_ops * ops) 


struct snd_device * dev; 


if(snd_BUG_ON( ! card || ! device, data || ! ops) ) 
return — ENXIO ; 

// 分 配 snd. device 所 需 空间 

dev = kzalloc( sizeof( * dev) ,GFP_KERNEL) ; 

if( dev == NULL) | 
snd, printk( KERN. ERR "Cannot allocate device Wn" ) ; 
return - ENOMEM ; 

} 

]/ 初 始 化 snd_device 信息 ,通过 参数 初始 化 设备 实例 化 信息 


dev -> card = card; 











dev —> type = type; 
// 表 明 设 备 状态 为 刚 建立 
dev —» state =SNDRV_DEV_BUILD; 
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dev -> device. data = device, data; 

dev —> ops = ops; 

// 加 入 card 的 管理 设备 链表 中 

list_add( &dev —> list, &card —» devices ) ; / * add to the head of list * / 


return 0; 


| 


每 种 类 型 的 子 设 备 都 是 通过 snd_device_new 接口 来 创建 设备 并 与 card 进行 关联 的 。 以 
control 子 设备 为 例 ，control 子 设备 是 通过 snd_ctl_create 创建 的 。 


int snd_ctl_create( struct snd_card * card) 
static struct snd_device_ops ops = | 
. dev. free = snd, ctl, dev. free, 
. dev. register = snd, ctl. dev. register, 
. dev. disconnect = snd, ctl, dev. disconnect, 


hs 


if( snd. BUG. ON( ! card) ) 
return — ENXIO ; 
return snd. device new( card, SNDRV. DEV CONTROL , card , &ops) ; 
| 


可 见 control 子 设 备 是 和 card 直接 关联 的 ， 也 说 明了 具体 的 控制 由 card 统一 来 执行 。 最 
终 card 以 及 子 设备 的 关联 关系 如 图 6-14 所 示 。 


snd_card 


list_head *devices 


snd_device snd_device snd_device > snd_device 


void *device_data 


图 6-14 snd_card 及 子 设备 关联 关系 


以 上 主要 是 设备 组 织 的 部 分 ， 与 设备 模型 的 注册 以 及 设备 文件 的 产生 并 没有 关联 。 思 
一 下 ， 这 些 工作 应 该 由 子 设备 自己 来 完成 ， 并 进行 文件 操作 的 设 定 ， 这 个 操作 就 是 由 snd_ 
device_ops 中 的 dev. register 操作 完成 的 。 相 应 的 ALSA 为 每 种 类 型 的 子 设备 提供 了 相关 的 接 
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口 snd_register_device_for_dev。 内 容 分 析 如 下 : 





int snd, register device, for dev( int type, struct snd_card * card, int dev, 





const struct file operations * f. ops, 
void * private data, 


const char * name, struct device * device ) 


int minor; 


struct snd, minor * preg; 


if( snd. BUG. ON( ! name) ) 
return — EINVAL; 
// 4] lii snd_minor 的 空间 ,用 于 运行 时 对 系统 内 设备 号 及 对 应 操作 的 管理 
preg = kmalloc ( sizeof * preg, GFP. KERNEL) ; 
if( preg == NULL) 
return - ENOMEM ; 
// 按 照 设备 类 型 等 传人 参数 初始 化 snd_minor 
preg —» type = type; 


preg —» card = card ? card -> number : -1; 











preg —> device = dev; 

preg —>f_ops = f ops; 

preg —> private_data = private_data; 

mutex_lock ( &sound_mutex ) ; 

// 根 据 设备 类 型 获得 子 设备 号 
#ifdef CONFIG_SND_DYNAMIC_MINORS 


minor = snd_find_free_minor( ) ; 





Helse 
/静态 方式 获得 
minor = snd_kernel_minor( type, card , dev) ; 
if( minor >=0 && snd_minors[ minor | ) 
minor = — EBUSY; 
#endif 
if( minor <0) | 
mutex, unlock ( &sound_mutex) ; 
kfree( preg) ; 
return minor; 
| 
// 加 入 系统 进行 管理 ,打开 文件 时 会 使 用 . 
snd_minors[ minor | = preg; 
// 创 建设 备 模型 管理 实体 ,其 中 设备 号 会 创建 相应 的 设备 文件 


preg -> dev = device_create( sound_class , device, MKDEV ( major , minor) , 
































private. data," 96s" ,name) ; 
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if( IS. ERR( preg —> dev) ) | 
snd_minors[ minor] = NULL; 
mutex, unlock ( &sound_mutex) ; 
minor = PTR, ERR( preg -> dev) ; 
kfree( preg) ; 


return minor; 


mutex, unlock ( &sound, mutex ) ; 


return 0; 


所 有 的 子 类 型 设备 都 会 在 其 dev. register 中 对 snd. register. device, for dev 进行 调用 ， 从 而 
完成 相关 的 注册 。 还 是 以 control 子 类 型 为 例 ; 








static int snd_ctl_dev_register( struct snd_device * device) 


| 


可 见 其 主要 工作 就 是 根据 card 号 为 设备 文件 指定 名 字 ， 然 后 完成 相关 的 注册 工作 。 


struct snd_card * card = device — > device_data; 
int err, cardnum; 


char name| 16 | ; 


if( snd. BUG, ON( ! card) ) 
return — ENXIO ; 
cardnum = card —> number; 
if( snd. BUG. ON( cardnum « 0 || cardnum >= SNDRV, CARDS) ) 
return — ENXIO; 
// 为 设备 文件 提供 名 字 
sprintf( name ," controlC% i" , cardnum) ; 
// 这 里 会 调用 snd_register_device_for_dev 来 完成 注册 功能 . 
if( (err = snd_register_device( SNDRV_DEVICE_TYPE_CONTROL, card, -1, 
&snd_ctl_f_ops,card,name) ) <0) 




















return err; 


return 0; 








接 下 来 看 看 具体 的 card 及 子 设备 的 初始 化 及 注册 流程 。 首 先 要 创建 card 实体 ， 相 应 的 
接口 是 snd_card_create， 详 细 分 析 如 下 : 








int snd_card_create( int idx ,const char * xid, 


struct module * module, int extra, size, 


struct snd, card * * card, ret) 
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struct snd_card * card; 


int err, idx2; 


if( snd. BUG, ON( ! card, ret) ) 
return — EINVAL; 
* card_ret = NULL; 


if( extra, size <0) 
extra, size 20; 
// 分 配 card 实体 的 空间 ,如 果 驱 动 通过 扩展 card 进行 管理 , 便 会 指定 extra, size 
card = kzalloc( sizeof( * card) + extra_size,GFP_KERNEL) ; 
if( ! card) 
return - ENOMEM ; 
if( xid) 
strlepy (card -> id , xid , sizeof( card -> id) ) ; 





























err =0; 

mutex, lock ( &snd_card_mutex) ; 

// 这 里 要 选 出 合适 的 card 号 ,如 果 ID Fy — 1 则 先 查 看 有 无 强制 匹配 关系 ,没有 则 分 配 
// 第 一 个 没有 占用 的 号 



































if(idx <0) | 
for(idx2 =0;idx2 <SNDRV_CARDS;idx2 ++ ) 
/ * idx == —1 ==Oxffff means; take any free slot * / 


if( ~ snd_cards_lock & idx & 1 << idx2) | 
if( module, slot, match ( module , idx2) ) | 


idx = idx2; 
break ; 
| 
| 
| 
if(idx «0) | 
for( idx2 20; idx2 < SNDRV. CARDS; idx2 ++ ) 
/ * idx == -1 ==Oxffff means; take any free slot * / 


if( ~ snd_cards_lock & idx & 1 << idx2) | 
if( ! slots[ idx2 | || ! * slots[ idx2 ] ) | 
idx = idx2; 
break ; 


| 
if(idx <0) 
err = - ENODEV; 
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else if( idx < snd_ecards_limit) | 
if( snd_cards_lock &(1 << idx) ) 
err = — EBUSY; / * invalid * / 
| else if( idx >= SNDRV, CARDS) 
err = — ENODEV; 
if( err <0) | 
mutex, unlock ( &snd. card. mutex ) ; 
goto __ error; 
| 
// 获 得 的 card 号 标记 占用 
snd_cards_lock | =1 << idx; / * lock it * / 
if( idx >= snd, ecards, limit ) 
snd, ecards, limit = idx + 1; / * increase the limit * / 
mutex, unlock ( &snd. card. mutex ) ; 
// ANKE. card 号 ,并 进行 初始 化 
card -> number = idx; 
card —> module = module; 
INIT_LIST_HEAD( &card -> devices) ; 
init_rwsem( &card —> controls_rwsem) ; 
rwlock, init( &card -> ctl, files rwlock) ; 
INIT LIST HEAD( &card -> controls) ; 
INIT LIST HEAD( &card -> ctl, files) ; 
spin, lock, init( &card —> files lock); 
INIT LIST HEAD( &card - > files list) ; 
init, waitqueue, head( &card -> shutdown, sleep) ; 
#ifdef CONFIG PM 
mutex, init( &card —» power. lock) ; 
init waitqueue head( &card -> power. sleep) ; 
#endif 
// 初 始 化 card 的 control 子 设备 
err = snd_ctl_create( card ) ; 
if(err «0) | 
snd, printk( KERN, ERR "unable to register control minors Wn" ) ; 
goto | error; 
| 
// 创 建 card 的 信息 ,通过 proe 文件 系统 输出 
err = snd_info_card_create( card ) ; 
if( err <0) | 
snd, printk( KERN, ERR "unable to create card info Wn" ) ; 


goto — error ctl; 





| 
// 如 果 驱 动 有 扩展 的 实体 , 则 在 card 尾部 开始 ,指针 则 要 初始 化 
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if( extra. size >0) 
card —> private_data = (char * ) card + sizeof( struct snd_card) ; 
* card_ret = card; 


return 0; 


__error_ctl: 
snd. device, free. all( card, SNDRV_DEV_CMD_PRE) ; 
__error; 
kfree( card) ; 
return err; 


| 








通过 分 析 可 见 ， 这 里 除了 对 card 的 空间 及 内 容 进 行 初始 化 外 ， 最 主要 的 就 是 对 control 
子 设备 初始 化 并 加 入 到 card 中 进行 管理 。 

分 配 了 card 之 后 ， 就 要 通过 snd_device_new 初始 化 并 加 入 必要 的 子 设备 ， 由 于 control 
已 经 加 入 ， 必 需 的 子 设备 就 是 pem (会 根据 需要 创建 playback 和 capture 两 种 文件 ) ， 通 过 
snd_pem_new 初始 化 并 加 入 到 card 中 。 最 后 通过 snd_card_register 来 完成 所 有 设备 的 注册 工 
作 。snd_card_register 细节 如 下 : 






































int snd_card_register(struct snd_card * card) 
| 
int err; 
if(snd_BUG_ON( ! card) ) 
return — EINVAL; 














// 这 里 创建 设备 模型 相关 实体 ,并 不 会 为 其 创建 设备 文件 
if( ! card —» card. dev) | 








card -> card, dev = device, create( sound, class ,card —> dev, 
MKDEV (0,0) ,card, 
"card% i" , card -> number) ; 
if( I5. ERR( card —» card, dev) ) 
card -> card. dev = NULL; 


// 对 所 有 的 子 设备 进行 注册 操作 

if( ( err = snd_device_register_all( card) ) <0) 
return err; 

mutex, lock ( &snd, card, mutex ) ; 

// 将 card 加 入 系统 进行 管理 

if(snd_cards[ card -> number | ) | 





/ * already registered * / 


mutex_unlock ( &snd_card_mutex ) ; 
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return 0; 
} 
snd_card_set_id_no_lock( card,card -> id| 0] =+ \0 ? NULL : card -» id) ; 
snd, cards[ card -> number | = card; 
mutex, unlock ( &snd. card. mutex ) ; 


init, info. for card( card) ; 








// 创 建 相关 sysfs 文件 
if(card -> card_dev) | 


T 


err = device, create, file( card -> card. dev , &card, id. attrs) ; 
if( err <0) 
return err; 
err = device, create, file( card -> card. dev, &card number attrs) ; 
if( err <0) 


return err; 


return 0; 


| 





其 中 除了 注册 系统 以 及 创建 sysfs 文件 外 ， 最 主要 的 就 是 通过 snd_device_register_all 进 
行 子 设备 的 注册 。snd_device_register_all 的 操作 很 简单 ， 就 是 遍历 card 的 devices 链表 ， 并 
调用 子 设备 的 dev register 接口 (最 终 调用 snd_register_device_for_dev 完成 注册 操作 ) ， 将 子 
设备 的 状态 标记 为 SNDRV_DEV_REGISTERED， 从 而 完成 整个 的 注册 流程 。 至 此 应 用 层 就 
可 以 使 用 相关 的 设备 文件 对 设备 进行 操作 了 。 

2. control 子 设备 

control 子 设备 主要 负责 card 中 所 包含 的 各 种 功能 的 设置 ， 这 些 设置 并 不 是 固定 于 子 设 
备 上 的 ， 而 是 属于 功能 型 的 ， 所 以 通过 card 直接 进行 管理 ， 将 一 个 控制 项 加 入 card 的 接口 
snd_ctl_add， 具 体 细节 如 下 . 












































int snd, ctl, add( struct snd_card * card, struct snd_kcontrol * kcontrol ) 
| 

struct snd_ctl_elem_id id; 

unsigned int idx; 


int err = — EINVAL; 


if( | kcontrol ) 
return err; 

if( snd. BUG. ON( ! card || ! kcontrol —> info) ) 
goto error; 

id = kcontrol -> id; 


down, write( &card —» controls rwsem) ; 
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// 检 查 control 是 否 已 经 加 入 ,主要 检查 类 型 ,设备 号 ,以 及 名 字 等 信息 
if( snd. ctl. find. id( card , &id) ) | 
up. write( &card -> controls. rwsem) ; 


snd, printd( KERN. ERR "control %i:%i:%i:%s:%i is already present Wn" , 





id. iface, 
id. device, 
id. subdevice, 
id. name, 
id. index) ; 
err = — EBUSY; 
goto error; 
} 
if( snd, ctl. find. hole( card , kcontrol -> count) <0) | 
up. write( &card -> controls rwsem) ; 
err = - ENOMEM ; 
goto error; 
} 
// 添 加 到 card 的 control 列表 中 
list_add_tail( &kcontrol -> list, &card —» controls) ; 
// 相 关 计数 增加 
card —> controls_count + = kcontrol —> count; 
kcontrol -> id. numid = card -> last_numid +1; 
card —» last, numid + = kcontrol — > count; 
up. write( &card -> controls. rwsem) ; 
// 通 知 control 的 增加 
for( idx 2 0 ;idx < kcontrol -> count; idx ++ ,id. index ++ ,id. numid ++ ) 
snd_ctl_notify (card, SNDRV_CTL_EVENT_MASK_ADD, &id) ; 


return 0; 

















error; 
snd_ctl_free_one(kcontrol) ; 


return err; 





从 以 上 代码 可 见 ， 音 频 控 制 的 主要 结构 就 是 snd_kcontrol， 详 细 内 容 如 下 : 


struct snd_kcontrol | 
// 用 于 control 的 连接 
struct list_head list; / * list of controls * / 
// 每 个 控制 的 基本 信息 ,包括 类 型 ,所属 设 备 ,名字 等 ,以 及 管理 的 编号 


struct snd_ctl_elem_id id; 


























可 




















unsigned int count; / * count of same elements * / 
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// 实 例 化 的 函数 接口 ,用 于 特定 的 控制 接口 
/获取 信息 接口 

snd_kcontrol_info_t * info; 

// 读 取 当 前 具体 的 设置 
snd_kcontrol_get_t * get; 

// 写 设置 的 接口 

snd_kcontrol_put_t * put; 

// 这 里 的 tlv Æ type — length — value 的 缩写 ,通常 包含 控制 中 更 完整 的 信息 


union | 












































snd_kcontrol_tlv_rw_t * c; 
const unsigned int * p; 
} tlv; 
// 通 常 是 该 控制 特殊 的 值 信息 
unsigned long private_value; 
// 通 常 是 该 控制 所 属 设备 的 相关 信 . 


void * private_data; 








èm 


void( * private free) ( struct snd_kcontrol * kcontrol ) ; 
// 一 个 控制 对 应 多 个 实体 时 ,这 里 是 多 个 实体 的 内 容 , 主要 是 与 文件 关联 的 属性 
// 以 及 对 应 的 访问 控制 


struct snd, kcontrol, volatile vd| 0 ] ; / * volatile data * / 














ls 





从 分 析 中 可 知 ， 每 一 个 控制 接口 可 以 将 多 个 相同 功能 统一 进行 管理 ， 而 其 中 的 元 素 就 使 
用 snd_ctl_elem_id 表示 ，count 表示 整体 的 管理 数目 ， 针 对 每 个 控制 实体 都 可 能 会 对 应 不 同 
用 户 任务 来 进行 操作 以 及 访问 控制 ， 这 些 都 属于 针对 应 用 层 变化 的 信息 ， 通 过 统一 的 snd_ 
kcontrol_volatile 来 进行 管理 。 对 应 控制 的 内 容 、 需 要 进行 设备 特殊 的 操作 ， 这 些 都 是 通过 
info, get, put 以 及 private_value 和 private, data 来 共同 实现 的 。 所 以 这 里 包括 了 针对 上 层 应 
用 层 的 管理 部 分 ， 以 及 针对 下 层 驱 动 的 操作 属性 。 

应 用 层 更 关注 的 是 控制 元 素 的 信息 以 及 相关 值 的 属性 ， 基 本 都 是 通过 snd_ctl_elem_xxx 
来 获得 的 ， 这 些 结构 定义 都 在 asound. h 中 。 

所 有 的 控制 都 是 底层 驱动 提供 的 ， 所 以 控制 信息 应 该 由 底层 驱动 进行 定义 ， 而 由 于 snd 
_kcontrol 中 包含 了 针对 上 层 的 管理 信息 ， 相 应 的 并 不 适用 于 底层 驱动 直接 定义 控制 信息 。 和 针 
对 这 种 情况 ，ALSA 框架 提供 了 snd_kcontrol_new 来 进行 定义 ,详细 内 容 如 下 : 




































































struct snd_kcontrol_new | 


// 控 制 元 素 的 类 型 





snd_ctl_elem_iface_t iface; / * interface identifier * / 

/设备 号 

unsigned int device; / * device/client number * / 

// 子 设备 

unsigned int subdevice; / * subdevice( substream ) number * / 
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unsigned char * name; / * ASCII name of item * / 





unsigned int index; / * index of item * / 

/访问 控制 

unsigned int access; / * access rights * / 

unsigned int count; / * count of same elements * / 


// 设 备 特殊 的 操作 接口 
snd_kcontrol_info_t * info; 
snd_kcontrol_get_t * get; 
snd_kcontrol_put_t * put; 
union { 
snd_kcontrol_tlv_rw_t * c; 
const unsigned int * p; 
} tlv; 
// 控 制 特殊 的 值 信息 ,可 以 赋予 指针 值 ,设备 操作 接口 会 进行 相应 转换 


unsigned long private_value; 











bs 








从 其 结构 体内 容 可 见 ， 其 中 主要 是 控制 与 设备 信息 的 设置 ， 符 合 底层 的 数据 特点 。 这 样 
就 需要 接口 能 将 底层 使 用 的 实体 转换 为 上 层 使 用 的 实体 ， 这 个 接口 就 是 snd_ctl_newl， 其 定 
义 如 下 : 





struct snd_kcontrol * snd_ctl_newl ( const struct snd_kcontrol_new * kcontrolnew , 


void * private_data) ; 











实际 应 用 中 通常 将 snd_ctl_add 与 snd_ctl_newl 结合 ， 就 可 以 完成 每 个 控制 元 素 的 注册 。 
驱动 部 分 的 控制 元 素 只 要 完成 注册 就 可 以 了 ， 而 在 上 层 中 针对 应 用 层 的 处 理 则 由 ALSA 提供 
的 control 子 设 备 的 操作 接口 来 完成 ， 主 要 将 每 个 kcontrol 的 元 素 看 做 element， 而 通过 snd_ 
ctl, elem, xxx 的 接口 进行 遍历 、 读 、 写 等 操作 (这 些 操作 都 是 ALSA 应 用 层 的 ioctl 命令 ) o 
这 样 就 完成 了 整个 的 控制 流程 ， 可 见 在 注册 之 后 控制 流 的 调用 层次 是 很 少 的 ， 主 要 因为 控制 
操作 本 来 就 是 很 直接 的 工作 ， 设 计 上 也 体现 了 这 种 直接 性 的 特点 。 
利用 kcontrol， 可 以 完成 对 音频 系统 中 的 mixer、mux、 音 量 控制 、 音 效 控制 以 及 各 种 
开关 量 的 控制 ， 这 些 操 作 都 是 通过 对 各 种 不 同类 型 kcontrol (不 同类 型 的 控制 元 素 ) 的 操 
作 来 完成 的 ， 通 过 这 些 控制 可 以 使 得 音频 设备 按照 应 用 的 设计 进行 工作 ， 完 成 各 种 音频 
需求 。 

以 上 是 control 子 设 备 中 包含 的 各 模块 功能 的 kcontrl 控制 部 分 ， 还 有 一 部 分 就 是 对 
card 其 他 类 型 子 设备 的 查询 等 控制 也 是 要 通过 control 子 设备 来 统一 完成 ， 这 样 可 以 有 统 
一 的 接口 来 遍历 整个 音频 设备 card 的 情况 ， 相 应 的 可 以 从 snd_ctl_ioctl 来 了 解 它 是 如 何 工 
作 的 。 































































































static long snd_ctl_ioctl( struct file * file, unsigned int cmd , unsigned long arg) 


| 
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struct snd_ctl_file * ctl; 

struct snd_card * card; 

struct snd_kctl_ioctl * p; 

void __user * argp = (void __user * ) arg; 
int __user * ip = argp; 


int err; 


ctl = file — > private, data; 
card = ctl -> card; 
if( snd. BUG. ON( ! card) ) 
return — ENXIO ; 
// 这 里 是 keontrol 的 操作 接口 
switch( cmd) } 
case SNDRV_CTL_IOCTL_PVERSION : 




















case SNDRV_CTL_IOCTL_CARD_INFO; 





return snd_ctl_card_info( card, ctl, emd , argp) ; 


case SNDRV_CTL_IOCTL_ELEM_LIST; 





return snd_ctl_elem_list( card, argp) ; 


case SNDRV_CTL_IOCTL_ELEM_INFO; 





return snd_ctl_elem_info_user( ctl, argp) ; 
case SNDRV. CTL IOCTL ELEM, READ: 
return snd, ctl, elem, read, user( card ,argp) ; 
case SNDRV. CTL IOCTL ELEM, WRITE: 
return snd, ctl. elem, write user( ctl, argp) ; 
case SNDRV. CTL IOCTL ELEM LOCK: 
return snd, ctl, elem lock( ctl, argp) ; 

case SNDRV. CTL. IOCTL ELEM. UNLOCK: 
return snd, ctl. elem, unlock( ctl , argp) ; 
case SNDRV. CTL IOCTL ELEM, ADD: 

return snd, ctl. elem, add, user( ctl, argp,0) ; 


case SNDRV. CTL IOCTL ELEM REPLACE: 




















return snd, ctl. elem, add, user( ctl , argp,1) ; 


case SNDRV. CTL. IOCTL. ELEM, REMOVE: 








return snd, ctl. elem, remove( ctl ,argp) ; 

case SNDRV. CTL IOCTL SUBSCRIBE EVENTS: 
return snd, ctl, subscribe events( ctl , ip) ; 
case SNDRV. CTL IOCTL TLV READ: 

return snd_ctl_tlv_ioctl( ctl, argp ,0) ; 

case SNDRV_CTL_IOCTL_TLV_WRITE; 

return snd_ctl_tlv_ioctl( ctl, argp,1) ; 

case SNDRV_CTL_IOCTL_TLV_COMMAND; 

















return put_user(SNDRV_CTL_VERSION, ip)? -EFAULT ; 
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return snd_ctl_tlv_ioctl( ctl, argp, — 1) ; 
case SNDRV. CTL IOCTL POWER: 
return - ENOPROTOOPT; 
case SNDRV. CTL. IOCTL POWER. STATE: 
#ifdef CONFIG. PM 
return put. user( card -> power state,ip)? — EFAULT ; 0; 





#else 
return put_user(SNDRV_CTL_POWER_DO,ip)? -EFAULT : 0; 
#endif 
} 
down_read( &snd_ioctl_rwsem) ; 
// 其 他 类 型 子 设备 的 ioctl 接口 ,用 来 获得 其 他 子 设备 的 情况 


list_for_each_entry( p,&snd_control_ioctls, list) | 








err = p —> fioctl( card , ctl, cmd, arg) ; 
if( err != ~ ENOIOCTLCMD) | 
up. read( &snd_ioctl_rwsem) ; 


return err; 


} 
up_read( &snd_ioctl_rwsem) ; 
snd_printdd(" unknown ioctl =0x% x\n" ,cmd ; 
return - ENOTTY ; 
} 


从 代码 中 可 以 了 解 keontrol 的 操作 方法 ， 另 外 还 提供 了 获得 其 他 子 设备 情况 的 接口 ， 
这 需要 其 他 类 型 子 设 备 如 pem 向 系统 注册 操作 接口 ， 通 过 snd_ctl_register_ioctl 加 入 链表 
snd_control_ioctls 进行 注册 。 这 样 的 设计 可 以 保证 应 用 通过 control 子 设备 来 查询 音频 设备 
的 整体 状况 并 进行 相关 的 操作 ， 这 样 可 以 有 统一 的 操作 界面 ， 适 合 应 用 的 需求 。 

3. pcm 子 设备 

前 面 介绍 了 音频 设备 的 控制 流程 ， 接 下 来 看 看 音频 设备 的 pem 数据 流程 。 对 pem 数据 
流 ，ALSA 设计 了 统一 的 管理 方式 ， 其 中 为 下 层 驱 动 提供 的 添加 pem 数据 通道 的 接口 函数 
snd_pcm_new， 详 细 内 容 以 及 分 析 如 下 : 









































int snd_pcm_new(struct snd_card * card , const char * id ,int device, 
int playback, count, int capture count, 


struct snd. pcm * * rpem) 


struct snd. pem * pem; 
int err; 
设备 管理 接口 


static struct snd_device_ops ops = | 





. dev. free = snd. pem. dev. free, 
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0) | 


. dev_register = snd pcm, dev. register, 
. dev. disconnect = snd. pem. dev. disconnect , 


E 


if( snd. BUG, ON( ! card) ) 
return — ENXIO ; 
if( rpem) 
* rpem = NULL; 
// 分 配 管理 实体 snd. pem 
pem = kzalloc(sizeof( * pem) ,GFP_KERNEL) ; 
if( pem == NULL) | 
snd, printk( KERN, ERR "Cannot allocate PCM\n" ) ; 
return - ENOMEM ; 





} 
//5 card 关联 
pcm —> card = card; 
// 记 录 子 类 型 设备 的 index 号 
pcm —> device = device; 
人 /记录 设备 名 
if(id) 
strlepy ( pem —> id, id, sizeof( pem —> id) ) ; 
// 添 加 管理 的 子 playback 流 , 可 以 是 多 个 
if( ( err = snd, pem, new, stream( pem, SNDRV_PCM_STREAM_PLAYBACK, playback, count) ) < 








snd, pem free( pem) ; 
return err; 
} 
// 添 加 管理 的 子 capture 流 ,可 以 是 多 个 
if( ( err = snd_pem_new_stream( pem, SNDRV_PCM_STREAM_CAPTURE, capture, count) ) <0) | 





snd, pem  free( pem) ; 
return err; 
} 
mutex, init( &pem -> open_mutex ) ; 
// 应 用 层 操 作 的 打开 控制 ,主要 是 避免 多 次 打开 ,因为 音频 数据 流 比较 敏感 
// 数 据 一 致 性 
init_waitqueue_head( &pem -> open, wait) ; 
// 加 入 card 进行 管理 ,后 续 的 card register 会 调用 snd. pem. dev. register 注册 
if( ( err = snd, device new( card, SNDRV_DEV_PCM, pem, &ops) ) «0) | 


snd, pem free( pem) ; 























return err; 


} 
if( rpem) 
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* rpcm = pcm; 


return 0; 





以 上 是 驱动 加 入 pem 流 的 过 程 ， 而 具体 的 注册 是 在 card register 中 调用 子 设备 的 snd 
pem. dev. register 来 完成 的 。 具 体内 容 如 下 : 





static int snd_pem_dev_register( struct snd_device * device) 
| 

int cidx, err; 

struct snd_pcm_substream * substream ; 

struct snd_pcm_notify * notify ; 

char str[ 16] ; 

struct snd, pem * pem; 


struct device * dev; 


if( snd. BUG. ON( ! device || ! device -> device. data) ) 
return — ENXIO ; 
// 通 过 snd. device 获得 pem 管理 实体 


pcm = device -> device. data; 























mutex, lock ( &register mutex) ; 

// 加 入 到 系统 中 允许 通过 control 子 设 备查 询 pem 信息 
err = snd. pem, add( pem) ; 

if( err) | 


mutex, unlock ( &register mutex) ; 





return err; 
| 
// 分 别 对 playback 和 capture 进行 不 同 的 操作 
for( cidx =0;cidx <2 ;cidx ++ ) | 
int devtype = -1; 
if( pem -> streams[ cidx ]. substream == NULL) 
continue ; 
// 7j playback 和 capture 设备 产生 合适 的 设备 名 
switch( cidx) | 
case SNDRV. PCM, STREAM, PLAYBACK : 
sprintf( str," pemC% iD% ip" , pcm —» card — > number, pem — > device) ; 
devtype  SNDRV. DEVICE TYPE PCM, PLAYBACK ; 
break ; 
case SNDRV_PCM_STREAM_CAPTURE; 
sprintf( str," pemC% iD% ic" , pem —» card -> number, pem — > device) ; 
devtype = SNDRV_DEVICE_TYPE_PCM_CAPTURE; 
break ; 
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| 
// 这 里 通常 是 该 pem 的 物理 设备 即 父 设备 ,一 般 都 是 空 ,所 以 父 设备 


// 会 是 card device 


























dev = pem -> dev; 
if( ! dev) 
dev = snd. card, get. device, link ( pem -> card) ; 
/ * register pem * / 
/注册 pem 到 系统 中 并 会 根据 信息 产生 设备 文件 ,设备 文件 操作 接口 
// 会 根据 playback 与 capture 有 不 同 . 


err = snd_register_device_for_dev( devtype, pem —> card, 














pcm -> device, 
&snd. pem f ops[ cidx | , 
pem, str, dev) ; 
if( err «0) | 
list, del( &pem - » list) ; 
mutex, unlock ( &register mutex) ; 
return err; 
} 
// 增 加 sysfs 文件 
snd_add_device_sysfs_file( devtype, pem —» card , pem —> device, 





&pem_attrs ) ; 
// 这 里 为 所 有 的 数据 流 创 建 向 应 用 层 提 供 信息 的 timer, 应 用 层 可 以 通过 
// 对 系统 的 timer 文件 来 对 音频 流 的 时 间 进 行 监控 . 一 般 不 使 用 该 功能 . 


for( substream = pem —> streams| cidx |. substream; substream ; substream = substream 一 > 


























next) 


snd, pem timer, init( substream) ; 














// 通 知 pem 已 经 注册 事件 
list, for each, entry ( notify , &snd. pem. notify. list , list) 








notify -> n register( pem) ; 


mutex, unlock ( &register mutex) ; 


return 0; 


从 添加 和 注册 的 细节 可 见 ，ALSA 框架 中 对 pem 进行 了 统一 的 管理 ， 由 snd_pem 来 提 
供 ， 而 其 中 会 根据 playback 和 capture 来 区 分 为 不 同类 型 的 snd_pcm_str， 在 不 同类 型 snd_ 
pem, str 中 则 可 以 有 多 个 substream 由 snd_pcm_substream 进行 管理 。 这 些 管理 实体 的 关系 如 
图 6-15 所 示 。 
所 有 这 些 管理 实体 snd_pcm 和 snd_pem_str 更 偏向 于 组 织 ， 而 snd_pcm_substream 是 
直接 对 应 到 实际 的 音频 流 ， 可 以 说 是 音频 设备 数据 流 的 核心 。 下 面 看 一 下 snd_pem_ 
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substream 的 详细 内 容 。 
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图 6-15 pem 中 管理 实体 关系 


struct snd_pem_substream | 


// 指 向 整体 pem 管理 实体 

struct snd_pem * pem; 

// 指 向 特定 方向 stream 的 管理 实体 (playback 或 者 capture) 

struct snd pem str * pstr; 

// 驱 动 相关 的 实体 ,主要 是 总 线 框架 使 用 如 USB 

void * private_data; / * copied from pem —> private_data * / 
// 同 方向 stream 的 index 号 


int number; 


char name| 32 | ; / * substream name * / 
// #878 stream 的 方向 playback 或 者 capture 
int stream; / * stream( direction) * / 


struct pm. qos request, list latency pm qos req; / * pm. qos request * / 

size t buffer bytes max; / * limit ring buffer size * / 

// 分 配 的 DMA 空间 的 信息 ,一 般 音 频 流 是 通过 DMA 传输 的 

struct snd_dma_buffer dma_buffer; 

// 如 果 使 用 reserve 空间 才 设置 ,通常 没有 为 音频 保留 空间 ,所 以 不 设置 该 什 
unsigned int dma_buf_id; 

// 设 置 的 DMA 分 配 的 最 大 空间 


size_t dma_max; 





/ * —-— hardware operations —— ** / 
// 人 硬件 相关 的 操作 

struct snd_pcm_ops * ops; 

/ * —— runtime information —— ** / 
// 运 行 时 pem 流 的 状态 , 145 24 B [vr NTT) A 


struct snd, pem runtime * runtime; 




















/* ——timer section 一 一 * / 
/由 于 音频 流 会 按照 一 定时 间 间 隔 传送 ,所 以 关联 到 向 应 用 层 通 知 时间 事 件 
struct snd_timer * timer; / * timer * / 
// 设 置 表示 启动 timer 功能 
unsigned timer_running: 1; / * time is running * / 
/ * —— next substream —— * / 























// 用 于 连接 substream 

struct snd_pcm_substream * next; 

/ * —- linked substreams -— * / 

//alsa 可 以 将 多 个 stream 关联 起 来 ,然后 统一 的 进行 操作 ,以 下 就 是 实现 
// 该 部 分 功能 的 相关 属性 


struct list_head link_list; / * linked list member * / 





struct snd. pcm, group self. group; / * fake group for non linked substream ( with substream 


lock inside) * / 


struct snd, pem, group * group; / * pointer to current group * / 
/ * —-— assigned files -— * / 
void * file; 


int ref count; 
//mmap 打开 的 数目 
atomic_t mmap_count; 

// 记 录 文 件 的 操作 属性 ,以 便 在 该 层 进行 相应 的 操作 


unsigned int f flags; 














void( ** pem. release) (struct snd. pem. substream * ) ; 


struct pid * pid ; 


/ ** misc flags * / 


unsigned int hw, opened: 1; 


E 





要 的 管理 实体 是 snd_pcm_runtime， 其 中 包含 了 运行 时 的 各 种 状态 和 属性 ， 与 音频 流 
目 关 。 具 体内 容 如 下 : 





A lg 


ag 
struct snd_pem_runtime | 

/ * ——Status -— * / 

// 记 录 各 种 状态 信息 

// 属 于 哪个 substream 触发 
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struct snd_pcm_substream * trigger_master; 





// 各 种 触发 事件 的 时 间 
struct timespec trigger_tstamp ; 
int overrange ; 


snd pem. uframes t avail max; 





snd. pem. uframes t hw. ptr. base; 





snd. pem, uframes, t hw. ptr. interrupt ; 





unsigned long hw. ptr jiffies; 
unsigned long hw. ptr buffer jiffies ; 


snd. pem, sframes. t delay; 


/* —— HW params -- ** / 

// BEVERS AE BL 

snd pcm. access, t access; 

// 采 样 数据 word 的 格式 

snd. pcm, format, t format; 

snd. pem, subformat, t subformat ; 
// 采 样 率 

unsigned int rate; 

//channel 数目 

unsigned int channels; 


snd pem. uframes t period size; 





unsigned int periods ; 


snd. pem. uframes t buffer. size; 





snd. pem, uframes t min, align; 





size t byte align; 
unsigned int frame bits; 
unsigned int sample. bits; 
unsigned int info; 
unsigned int rate num; 


unsigned int rate. den; 


/* ——SW params —— */ 
int tstamp. mode ; 
unsigned int period. step; 


snd. pem. uframes t start. threshold ; 





snd. pem. uframes t stop. threshold ; 





snd. pem. uframes t silence threshold ; 





/ * trigger timestamp * / 


/ * Position at buffer restart * / 

/ * Position at interrupt time * / 

/ * Time when hw. ptr is updated * / 
/ * buffer time in jiffies * / 


/ * extra delay ;typically FIFO size * / 


/ * access mode * / 


/ * SNDRV. PCM, FORMAT * */ 


/ * subformat * / 
/ * rate in Hz * / 
/ * channels * / 
/ * period size * / 
/ * periods * / 


/ * buffer size ** / 


/ * Min alignment for the format * / 


/ * mmap timestamp is updated * / 


/ * Silence filling happens when 


noise is nearest than this * / 


snd. pem, uframes, t silence, size; 





snd. pem, uframes, t boundary ; 


/ * Silence filling size ** / 


/ ** pointers wrap point * / 


snd_pcm_uframes_t silence_start; / * starting pointer to silence area * / 








snd. pem. uframes t silence. filled; / * size filled with silence * / 
union snd. pem. sync. id syne; / * hardware synchronization ID * / 
/* ——mmap —-- */ 



































// 以 下 信息 可 以 通过 mmap 命令 map 到 用 户 空 间 供用 户 获 得 状态 信息 并 使 用 
// 运 行 时 内 存 空 间 的 操作 状态 包括 地 址 位 置 PY Ti] 

struct snd. pem mmap. status * status; 

/应 用 层 操作 的 偏 移 信息 等 


struct snd_pcm_mmap_control * control ; 
































/ * —- locking/scheduling —— * / 


snd. pem, uframes t twake; / * do transfer( | poll) wakeup if non — zero * / 
wait queue, head. t sleep; / * poll sleep * / 
wait queue head t tsleep; / * transfer sleep * / 


struct fasync, struct * fasync; 


/** —— private section —— ** / 
void * private data; 


void( * private, free) ( struct snd, pem, runtime * runtime) ; 


/ * —-— hardware description 一 一 * / 
// 便 件 信息 描述 





struct snd_pcm_hardware hw; 


struct snd_pcm_hw_constraints hw. constraints ; 


/ * —-interrupt callbacks -— * / 
void( * transfer ack begin) (struct snd_pem_substream * substream ) ; 


void( * transfer ack end) ( struct snd. pem, substream * substream) ; 


/* ——timer —— */ 
unsigned int timer, resolution; / ** timer resolution * / 
int tstamp. type; / * timestamp type * / 


/* --DMA —- */ 
//DMA 使 用 的 属性 ,包括 内 存 空间 描述 等 信息 








unsigned char * dma_area; / * DMA area * / 

dma_addr_t dma_addr; / * physical bus address( not accessible from main 
CPU) */ 

size t dma, bytes; / * size of DMA area * / 
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l5 


可 见 其 很 多 属 HAM {他 管理 实体 中 复制 过 来 也 





struct snd_dma_buffer * dma_buffer_p; / * allocated buffer * / 








J, EHE dma 空间 的 


属性 ， 以 及 其 中 一 























ee 性 等 ， 这 是 为 了 操作 的 方便 ; runtime 的 状态 更 新 涉及 上 层 应 用 和 底层 驱动 ， 
主要 是 运行 时 的 状态 、 音 频 流 状态 的 更 新 ， 系 统 提 供 了 统一 的 接口 进行 相应 的 更 新 操作 ， 如 
snd pem update, hw. ptr 和 snd_pcm_period_elapsed (驱动 进行 更 新 的 接口 ) 。 








_pem_period_elapsed 的 具体 内 容 : 


void snd_pcm_period_elapsed( struct snd_pcm_substream * substream ) 


| 


struct snd_pcm_runtime * runtime; 


unsigned long flags; 


if( PCM, RUNTIME CHECK( substream) ) 
return; 


runtime = substream —> runtime; 


if( runtime —» transfer ack begin) 


runtime — » transfer ack, begin( substream) ; 


snd. pem, stream, lock irqsave( substream , flags) ; 
// 检 查 是 否 pem 处 于 传输 状态 ,如 是 , 则 根据 runtime 的 信息 更 新 相关 状态 
/内 存 地 址 和 时 间 戳 等 信息 


if( | snd. pem. running( substream) || 











snd, pem update hw. ptrO( substream,1) <0) 


goto end; 





// 更 新 timer 相关 信息 


if( substream — > timer running) 





snd, timer. interrupt( substream — > timer, 1) ; 


end: 





snd. pem, stream, unlock, irqrestore( substream , flags ) ; 
if( runtime —» transfer ack, end) 
runtime — » transfer. ack, end( substream ) ; 
// 异 步 通知 应 用 层 , 一 般 mmap 方式 需要 
kill, fasync( &runtime —> fasyne ,SIGIO , POLL IN) ; 















































下 面 来 看 看 snd 


eee 


这 里 有 一 个 重要 的 概念 就 是 周期 (period) ， 这 是 因为 一 次 DMA 操作 唤醒 一 次 中 断 太 浪 
费 系统 资源 ， 所 以 通常 定义 一 个 数据 块 大 小 表示 一 个 周期 可 以 传送 数据 的 大 小 ， 这 样 的 设计 
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考虑 整体 的 系统 性 能 。 
对 驱动 来 说 ， 重 要 接口 是 设置 snd_pcm_runtime 中 的 snd_pcm_ops。snd_pcm_ops 的 具体 
内 容 如 下 : 





struct snd_pem_ops | 
int( * open) (struct snd_pem_substream * substream) ; 
int( * close) ( struct snd_pem_substream * substream) ; 
//ioctl 的 接口 
int( * ioctl) (struct snd_pem_substream * substream, 
unsigned int cmd, void * arg) ; 
// 在 传输 之 前 进行 硬件 参数 设置 的 接口 
int( * hw_params) ( struct snd_pem_substream * substream, 
struct snd_pcm_hw_params * params) ; 
/人 /硬件 释放 的 接口 
int( * hw. free) (struct snd_pem_substream * substream ) ; 
// 传 输 之 前 的 准备 操作 的 接口 
int( * prepare) ( struct snd_pem_substream * substream) ; 
// 各 种 状态 转换 的 接口 
int( * trigger) (struct snd_pem_substream * substream ,int cmd) ; 
// 获 得 当前 硬件 操作 DMA 空间 指针 状态 ,返回 数据 的 当前 读 取 位 置 (capture) 
// 或 数据 的 当前 写 和 位置 ( playback ) 
snd. pem, uframes t( * pointer) (struct snd_pem_substream * substream) ; 
// 便 件 进行 数据 拷贝 的 接口 


int( * copy) (struct snd_pem_substream * substream, int channel, 
































snd pcm, uframes t pos, 
void ^ user * buf,snd. pcm, uframes t count) ; 
int( * silence) (struct snd. pem, substream * substream, int channel, 
snd. pem, uframes, t pos ,snd_pcm_uframes_t count) ; 
// 内 存 空间 缺 页 异常 的 操作 接口 


struct page * ( * page) (struct snd_pem_substream * substream, 





unsigned long offset) ; 
// 进 行 mmap 操作 接口 
int( * mmap) (struct snd_pem_substream * substream, struct vm, area, struct * vma) ; 
// 应 用 读 写 需要 硬件 进行 同步 的 接口 


int( * ack) (struct snd_pem_substream * substream) ; 

















bs 





驱动 主要 就 是 实现 这 些 接口 ， 并 通过 snd pem. set ops 进行 设置 。 
而 应 用 层 的 各 种 操作 会 使 得 PCM 流 在 不 同 的 状态 中 转换 ， 具 体 的 状态 如 下 : 











#define SNDRV_PCM_STATE_OPEN ((_ force snd_pem_state_t)0) 
#define SNDRV_PCM_STATE_SETUP ((_ force snd_pem_state_t) 1) 
#define SNDRV_PCM_STATE_PREPARED ((_ force snd_pem_state_t)2) 
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#define SNDRV_PCM_STATE_RUNNING ((_ force snd_pem_state_t) 3) 
#define SNDRV_PCM_STATE_XRUN ((_ force snd_pem_state_t)4) 
#define SNDRV_PCM_STATE_DRAINING ((_ force snd_pem_state_t)5) 
#define SNDRV_PCM_STATE_PAUSED ((_ force snd_pem_state_t)6) 
#define SNDRV_PCM_STATE_SUSPENDED ((_ force snd_pem_state_t)7) 
#define SNDRV_PCM_STATE_DISCONNECTED ((_ force snd_pem_state_t) 8) 





ALSA 的 框架 会 针对 不 同 的 操作 调用 合适 的 驱动 snd_pem_ops #20 KA, Muf oe oer à 
的 操作 。 

对 整体 的 pem 子 设备 的 理解 ， 同 样 要 分 为 控制 部 分 和 数据 部 分 ， 控 制 部 分 就 是 各 种 命 
令 使 得 pom 流 在 不 同 状态 间 进 行 转换 。 基 本 的 控制 流程 是 用 户 通过 open 打开 子 码 流 并 获得 
该 子 码 流 的 能 力 参数 ， 从 而 确定 出 一 套 可 用 的 参数 ; 调用 hw_params 设置 这 些 参 数 ; 调用 
prepare 进行 最 后 的 准备 工作 ， 比 如 清除 fifo; 调用 trigger 启动 或 停止 工作 ; 通过 pointer 了 解 
工作 进展 ; 工作 停止 后 ， 调 用 hw_free 释放 资源 ， 使 用 close 关闭 子 码 流 。 而 数据 部 分 是 通过 
runtime 进行 状态 的 维护 和 同步 ， 由 应 用 层 的 read, write 或 者 mmap 方式 和 驱动 (DMA 的 方 
式 ) 共同 操作 ring buffer 的 空间 ， 从 而 完成 整个 的 数据 操作 。 

对 数据 部 分 ， 应 用 层 read 和 write 音频 流 数 据 需要 考虑 数据 的 组 织 形式 ， 通 过 不 同 的 
ioctl 命令 来 完成 ， 当 多 个 channel 的 音频 数据 放 在 同一 块 连续 存储 空间 时 是 属于 interleave 方 
式 存 放 ， 需 要 进行 readi 和 writei 操作 ; 否则 就 是 不 同 的 channel 数据 放 人 分 离 的 存储 空间 
中 ， 需 要 通过 readn 和 writen 进行 操作 。 应 用 层 需要 根据 数据 的 具体 属性 进行 相关 的 操作 。 
这 样 框架 层 就 完成 了 数据 的 操作 ， 其 余 的 数据 操作 属于 驱动 的 实现 部 分 。 

4. ASoC (ALSA SoC) 子 框架 

以 上 的 框架 主要 适合 于 PC 上 的 音频 设备 ， 这 些 音频 设备 的 特定 是 数字 部 分 和 模拟 部 分 
集成 在 一 起 ， 所 以 通过 统一 的 控制 就 可 以 完成 。 而 随 着 般 入 式 的 发 展 ，SoC 处 理 需 大 量 地 出 
现 ， 这 些 SoC 的 特点 是 在 片上 包含 音频 数据 流 的 传输 通道 ， 而 具体 的 音频 处 理 以 及 模拟 部 分 
是 在 SoC 外 部 的 音频 codec 进行 处 理 的 ， 这 就 使 通道 和 处 理 是 分 离 的， 这 样 设计 的 特点 是 使 
得 数字 部 分 和 模拟 部 分 隔离 ， 降 低 芯 片 开发 的 难度 ， 也 可 以 集成 不 同 的 codec 来 完成 不 同 的 
功能 。 在 软件 上 这 就 带 来 了 问题 ， 之 前 的 架构 对 SoC 来 说 并 不 适用 。 如 果 使 用 原 有 的 音频 框 
架 ， 要 完成 SoC 音频 数据 接口 的 驱动 还 需要 包括 音频 codec 的 操作 ， 这 样 才 是 完整 的 音频 设 
备 ， 这 样 就 不 能 在 不 同 的 SoC 之 间 重 用 音频 codec 的 驱动 ， 从 而 提高 了 系统 的 复杂 程度 。 为 
了 解决 这 些 问 题 ，ALSA 提供 了 ASoC 子 架 构 ， 如 图 6-16 所 示 。 

从 图 6-16 可 见 ，ALSA SoC 将 不 同 的 设备 主要 分 为 machine, codec 和 platform 几 个 部 
分 。codec 主要 负责 audio codec 部 分 ; platform 主要 负责 音频 流 的 传输 控制 ，machine 则 是 描 
述 相 关 的 连接 ， 使 得 ALSA SoC 框架 可 以 将 这 些 分 离 的 组 件 进行 正确 的 连接 。 另 外 audio co- 
dec 和 SoC 都 包含 数据 通道 的 控制 ， 在 ALSA SoC 框架 中 称 为 DAI (digital audio interfaces ) 
这 部 分 的 属性 和 控制 单独 进行 管理 ， 在 audio codec 和 platform 双方 都 有 相应 的 管理 实体 和 操 
作 。 这 样 整体 上 系统 就 可 以 分 离 成 各 种 不 同 的 管理 实体 ， 各 种 实体 可 以 分 别 进行 驱动 的 开 
发 ， 最 终 通过 machine (相当 于 板 级 的 连接 管理 ) 将 这 些 实体 关联 成 系统 ， 从 而 使 得 整个 系 
统 正常 工作 。 
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图 6-16  alsa soc 框架 








ALSA SoC 框架 针对 以 上 的 实体 分 别提 供 了 不 同 的 管理 结构 ， 具 体 如 下 : 
snd soc dai; 用 于 描述 SoC 处 理 器 端 或 codec 端 接口 的 硬件 能 力 。 在 运行 过 程 中 ， 
ASoC 框架 会 综合 两 端的 硬件 能 力 ， 生 成 两 端 都 可 接收 硬件 能 力 参数 (snd_pcm_hard- 
ware), 
snd, soc, platform; 用 于 管理 SoC A38 gm ICD it ERE o 
snd. soc, dai link; 用 于 描述 SoC 处 理 器 端 和 codec 端 两 端的 实际 硬件 连接 。 即 SoC 处 
理 需 端 哪个 硬件 通道 与 哪个 codec 进行 连接 。 
snd soc card; 用 于 描述 所 有 的 硬件 连接 ， 最 终 会 建立 一 个 card， 而 每 个 连接 会 建立 
一 个 pem 通道 。 

© snd soc codec; 用 于 描述 audio codec 属性 ， 以 及 相关 操作 。 

而 以 上 所 有 这 些 硬件 连接 的 各 个 模块 都 通过 snd_soc_pcm_runtime 进行 关联 ， 其 内 容 
如 下 : 





n» 
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struct snd_soc_pem_runtime | 


| 


从 结构 的 实际 属性 可 见 ， 其 中 将 ALSA SoC 下 层 具 体 的 功能 模块 与 上 层 ALSA 的 pem Pi 


进行 了 关联 ， 


细 分 析 如 下 : 


struct device dev; 
struct snd_soc_card * card; 


struct snd_soc_dai_link * dai_link; 





unsigned int complete :1 ; 


unsigned int dev. registered :1 ; 


/ * Symmetry data — only valid if symmetry is being enforced * / 
unsigned int rate; 


long pmdown_time; 


/ * runtime devices * / 

struct snd_pem * pem; 

struct snd_soc_codec * codec; 
struct snd_soc_platform * platform; 
struct snd_soc_dai * codec_dai; 


struct snd_soc_dai * cpu_dai; 


struct delayed_work delayed_work ; 














这 样 就 建立 了 上 层 与 下 层 的 连接 ， 保 证 操作 的 畅通 。 








static int soc_bind_dai_link (struct snd_soc_card * card, int num) 


| 
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struct snd_soc_dai_link * dai link = &card -> dai_link[ num] ; 





struct snd, soc, pem, runtime * rtd = &card -> rtd[ num] ; 
struct snd, soc, codec * codec; 

struct snd, soc. platform * platform; 

struct snd, soc. dai * codec, dai, * cpu. dai; 

// 已 经 绑 定 则 直接 返回 

if( rtd -> complete) 





return 1; 


dev. dbg( card -> dev," binding 96s at idx % d\n" , dai. link -> name, num) ; 


/ ** do we already have the CPU DAI for this link ? * / 
/ 绑 定 处 理 器 侧 的 DAL 
if( rtd -> cpu. dai) | 








ALSA SoC 框架 则 提供 将 底层 各 个 模块 关联 的 操作 ， 通 过 soc bind dai link 来 进行 ， 详 


goto find codec ; 
| 
/ ** no,then find CPU DAI from registered DAIs * / 
list. for each, entry( cpu, dai , &dai_list, list) | 


if( ! stremp( epu, dai -> name, dai. link -> cpu, dai, name) ) | 


if( ! try. module, get( cpu, dai -> dev —» driver -> owner) ) 
return - ENODEV ; 


rtd —» cpu. dai = cpu, dai; 


goto find codec; 


} 
dev_dbg( card -> dev," CPU DAI 96s not registered Wn" , 


dai. link -> cpu. dai name) ; 


find. codec: 
/ * do we already have the CODEC for this link ? * / 
// 绑 定 codec 
if( rtd —> codec) | 
goto find. platform ; 


/ * no,then find CODEC from registered CODECs * / 
// 查 询 每 个 注册 的 codec 
list_for_each_entry( codec , &codec, list , list) | 
if( ! stremp( codec —> name, dai, link -> codec, name) ) | 
// Sf XE codec 


rid —» codec = codec; 


if( ! try_module_get( codec — > dev —> driver -> owner) ) 
return - ENODEV ; 


/ ** CODEC found,so find CODEC DAI from registered DAIs from this CODEC * / 
// 查 找 并 绑 定 codec 侧 的 DAT 
list_for_each_entry( codec, dai , &dai_list, list) | 
if(codec -> dev == codec_dai -> dev && 
! stremp( codec, dai -> name, dai_link -> codec, dai, name) ) | 
rtd —> codec, dai = codec, dai; 


goto find. platform ; 
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dev. dbg( card -> dev," CODEC DAI 46 s not registered Wn" , 


dai, link — > codec, dai, name) ; 
goto find. platform ; 


} 
dev_dbg( card -> dev," CODEC %s not registered\n" , 


dai, link —» codec, name) ; 


find. platform: 
// 绑 定 处 理 器 侧 的 数据 操作 管理 实体 platform 
if( rtd —> platform) | 




















goto out ; 


| 
/ * no,then find CPU DAI from registered DAIs * / 


list for each, entry( platform , &platform, list , list) | 


if( ! stremp( platform -> name, dai, link -> platform. name) ) | 


if( ! try. module, get( platform -> dev —> driver -> owner) ) 
return - ENODEV ; 


rtd —> platform = platform; 


goto out; 


dev_dbg( card -> dev," platform 96s not registered Wn" , 
dai. link -> platform, name) ; 


return 0; 


out : 
/ * mark rtd as complete if we found all 4 of our client devices * / 
上 /所 有 需要 的 模块 都 已 经 绑 定 则 表示 绑 定 完成 ,设置 标识 . 
if( rtd -> codec && rtd ->codec_dai && rtd ->platform && rtd —» cpu, dai) | 





rid -> complete 21; 
card -> num, rtd ++ ; 


| 


return 1; 


从 代码 中 可 见 ， 只 有 rtd -> codec, rtd -> codec, dai, rtd -> platform 和 rtd -> cpu, dai 都 


y 


绑 定 才 是 真正 的 绑 定 成 功 ， 从 而 进行 后 续 操 作 。 对 于 每 种 组 件 ALSA SoC 框架 都 提供 注册 接 
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口 ， 接 口 如 下 : 


int snd_soc_register_dai( struct device * dev, struct snd_soc_dai_driver * dai_drv) ; 

int snd, soc, register codec( struct device * dev, struct snd_soc_codec_driver * codec, drv, 
struct snd, soc, dai, driver ** dai, drv,int num, dai) ; 

int snd, soc, register platform( struct device * dev, 


struct snd, soc. platform. driver * platform. drv) ; 


各 个 组 件 会 在 内 部 通过 以 上 接口 向 ALSA SoC 注册 相应 的 组 件 。 为 了 适应 各 种 不 同 的 组 
件 注 册 情 况 ， 系 统 提 供 了 整体 的 card 级 别 的 初始 化 操作 ， 并 会 在 任何 组 件 注册 时 被 调用 ， 
保证 系统 能 正确 地 发 现 不 同 的 组 件 并 关联 。 这 个 逻辑 最 终 由 snd_soc_instantiate_card 来 完成 ， 
详细 内 容 如 下 : 





static void snd_soc_instantiate_card( struct snd_soc_card * card ) 
struct platform_device * pdev = to_platform_device( card -> dev) ; 


int ret ,1; 


mutex_lock ( &card -> mutex) ; 


// 已 经 完成 实例 化 
if( card —> instantiated ) | 
mutex, unlock ( &card -> mutex) ; 


return ; 


/ * bind DAIs * / 

// 进 行 所 有 物理 连接 的 各 个 模块 绑 定 

for(i=0;i<card -> num links;i ++ ) 
soc, bind. dai link( card, i) ; 





/ * bind completed ? * / 
/所 有 物理 连接 都 完成 绑 定 ,才能 继续 


if( card —> num, rtd != card -> num links) | 





mutex, unlock ( &card -> mutex) ; 


return ; 


/ * card bind complete so register a sound card * / 

// 创 建 ALSA 层 的 card 管理 实体 

ret = snd_card_create( SNDRV_DEFAULT_IDX1 ,SNDRV_DEFAULT_STRI, 
card —» owner,O , &card -> snd, card) ; 


if( ret «0) | 
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printk( KERN, ERR "asoc: cari t create sound card for card % s\n" , 
card —» name) ; 
mutex, unlock ( &card -> mutex) ; 
return ; 
} 
/设备 模型 的 层次 关系 


card ->snd_card -> dev = card —> dev; 


#ifdef CONFIG_PM 

/ * deferred resume work * / 

INIT_WORK( &card -> deferred, resume, work ,soc_resume_deferred ) ; 
#endif 





/ * initialise the sound card only once * / 
if( card -> probe) | 

ret = card -> probe( pdev) ; 

if( ret «0) 


goto card. probe, error; 


for(i =0;i «card -» num links;i ++ ) | 
// 检 查 物理 连接 的 各 个 组 件 并 进行 探测 操作 ,进行 必要 的 初始 化 添加 control 
// 最 终 还 会 通过 soc_new_pem 创建 pem 实体 
ret = soc_probe_dai_link( card,i); 
if( ret <0) | 


pr err("asoc; failed to instantiate card 96s; % d\n", 











card —» name, ret) ; 


goto probe_dai_err; 


snprintf( card — > snd_card —> shortname , sizeof ( card -> snd_card -> shortname) , 
"Gs" , card —» name); 
snprintf( card — > snd_card -> longname , sizeof ( card -> snd_card -> longname) , 


"Gs" card —» name); 





// 完 成 ALSA 层 card 的 注册 ,并 创建 对 应 的 文件 
ret = snd_card_register( card -> snd card) ; 
if( ret «0) | 
printk( KERN, ERR "asoc; failed to register soundcard for % s\n" , card -> name) ; 


goto probe. dai, err; 
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// 实 例 化 完成 设置 标识 
card -> instantiated = 1 ; 
mutex, unlock ( &card -> mutex) ; 


return ; 


probe_dai_err: 
for(i =0;i < card -> num links;i ++ ) 


soc_remove_dai_link( card ,i) ; 


card probe error; 
if( card —> remove ) 


card —» remove( pdev) ; 
snd_card_free( card -> snd_card) ; 
mutex, unlock ( &card -> mutex) ; 
从 代码 分 析 可 见 ， 主 要 是 对 ALSA 层 的 设备 管理 部 分 的 封装 ， 通 过 内 部 的 各 个 组 件 的 操 
作 来 完成 整体 的 注册 过 程 。 


对 control 子 设备 ， 主 要 是 注册 control 元 素 ; 而 对 pem 子 设 备 ， 则 通过 snd pem, set ops 
将 pem 管理 实体 中 snd_pem_ops 重新 定义 为 soc_pcm_ops， 具 体内 容 如 下 : 























static struct snd_pem_ops soc, pem. ops = | 





. open = soc_pcm_open, 

. close = soc, codec, close, 

. hw. params = soc pcm hw. params, 
. hw. free -soc pem, hw, free, 

. prepare = soc, pem, prepare, 

. trigger = soc, pem, trigger, 

. pointer = soc pem, pointer, 


E 


这 样 上 层 的 操作 就 可 以 转 和 人 ALSA SoC 层 执行 。 以 soc. pem. hw. params 为 例 来 看 看 具体 
的 操作 : 


static int soc_pem_hw_params( struct snd, pem. substream * substream, 


struct snd, pem, hw. params * params) 


struct snd, soc. pem, runtime * rtd = substream —> private, data; 


struct snd, soc. platform * platform = rtd -> platform; 
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struct snd_soc_dai * cpu, dai = rtd —» cpu. dai; 
struct snd, soc, dai * codec, dai = rtd -> codec, dai ; 


int ret 20; 


mutex, lock ( &pem, mutex ) ; 


/物理 连接 级 别 的 操作 ,主要 进行 统一 的 设置 


if( rtd -> dai link ->ops && rtd -> dai, link ->ops — > hw_params) | 





ret = rtd -> dai, link —» ops —» hw_params(substream, params) ; 
if( ret <0) | 
printk( KERN_ERR "asoc; machine hw_params failed\n" ) ; 


goto out; 


//codec 侧 数据 接口 的 设置 


if( codec. dai -> driver -> ops —> hw. params) | 





ret = codec, dai -> driver -> ops -> hw, params( substream , params , codec, dai ) ; 
if( ret « 0) | 
printk( KERN, ERR "asoc: cari t set codec 96s hw params Wn" , 
codec. dai -> name) ; 


goto codec, err; 


// hb E de DU OIE e O RS ER 
if( epu, dai -> driver -> ops -> hw, params) | 
ret = cpu, dai -> driver -> ops —> hw. params( substream , params , cpu, dai ) ; 
if( ret «0) | 
printk( KERN, ERR "asoc; interface 96s hw params failed Yn" , 
cpu. dai —» name) ; 


goto interface erm; 


// Bb E die DU f D P E E BR RS E 


if( platform -> driver -> ops -> hw, params) | 





ret = platform — > driver -> ops -> hw. params( substream , params) ; 
if( ret <0) | 
printk( KERN, ERR "asoc; platform 96 s hw params failed Wn" , 
platform -> name) ; 


goto platform, err; 
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rtd —» rate = params_rate( params) ; 


out: 
mutex, unlock ( &pem_mutex ) ; 


return ret; 


platform, err; 
if( cpu, dai -> driver -> ops -> hw, free) 


cpu. dai -> driver -> ops -> hw, free( substream , cpu. dai ) ; 


interface, err; 
if( codec, dai -> driver -> ops — > hw. free) 


codec, dai -> driver -> ops -> hw, free( substream , codec, dai ) ; 


codec. err: 
if( rtd -> dai, link -> ops && rtd -> dai. link —> ops — > hw, free) 
rtd —» dai. link -> ops — > hw. free( substream) ; 


mutex, unlock ( &pem, mutex) ; 


return ret ; 


可 见 其 主要 的 功能 就 是 按照 一 定 的 顺序 对 各 个 组 件 进 行 相关 的 操作 ， 这 样 整 个 pem 的 
操作 就 从 上 到 下 打通 了 。 

最 后 对 SoC 处 理 器 来 说 ， 大 部 分 的 设备 都 是 以 platform device 出 现 的 ， 对 ALSA SoC 的 
架构 也 要 考虑 到 这 一 点 ， 其 整体 上 定义 为 platform driver， 与 整个 SoC 系统 关联 ， 细 节 
如 下 : 











static struct platform_driver soc. driver = | 


. driver = 
. name =" soc — audio" , 
. owner = THIS MODULE, 
.pm = &soc pm ops, 

he 

. probe =soc_probe, 

. remove = soc_remove , 


z 





这 样 ALSA SoC 中 machine 层面 只 要 注册 对 应 的 platform device 就 可 以 通过 bus 完成 整 
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体 的 操作 ， 其 中 soc, probe 会 试图 进行 soc card 的 实例 化 ， 而 每 个 组 件 也 都 可 以 通过 plat- 

form driver 的 方式 与 实际 的 SoC 处 理 右 中 设备 关联 ， 这 样 在 probe 中 注册 对 应 的 ALSA SoC 

组 件 ， 就 可 以 在 底层 保证 整个 物理 连接 的 各 个 设备 最 终 关 联 组 成 上 层 针 对 应 用 的 音频 设 

备 ， 这 样 的 设计 ， 既 体现 了 设备 层次 ， 也 体现 了 物理 连接 的 实际 情况 ， 是 一 种 灵活 好 用 
不 
































文 
的 框架 。 
这 样 音频 设备 框架 的 整体 层次 就 介绍 完了 。 


音频 驱动 应 用 层 操作 及 框架 适 配 
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应 用 程序 主要 分 为 控制 和 pem 流 的 操作 两 部 分 。 下 面 以 两 个 例子 进行 介绍 。 

首先 介绍 控制 部 分 的 操作 ， 对 音频 的 控制 ， 主 要 是 各 个 不 同 通道 mixer 的 控制 ， 下 面 先 
看 看 打开 的 流程 : 











6. 3 





struct mixer * mixer_open( unsigned int card) 
| 

struct snd_ctl_elem_list elist; 

struct snd_ctl_elem_info tmp; 

struct snd_ctl_elem_id * eid = NULL; 

struct mixer * mixer = NULL; 

unsigned int n,m; 

int fd; 

char fn[ 256 | ; 


snprintf( fn , sizeof( fn) , " /dev/snd/controlC46 u" ,card) ; 
// 打 开 相 应 的 设备 

fd = open(fn,O RDWR) ; 

if(fd <0) 


return 0; 


memset( &elist ,0 , sizeof( elist) ) ; 

// 首 先 获得 控制 信息 的 个 数 

if(ioctl({d,SNDRV_CTL_IOCTL_ELEM_LIST, &elist) <0) 
goto fail; 




















mixer = calloc( 1 , sizeof( * mixer) ) ; 
if( | mixer) 


goto fail ; 


mixer —> ctl = calloc( elist. count, sizeof( struct mixer. ctl) ) ; 
mixer —> info = calloc( elist. count, sizeof( struct snd, ctl, elem info) ) ; 
if( | mixer —» ctl || ! mixer -> info) 


goto fail ; 
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eid = calloc( elist. count , sizeof( struct snd_ctl_elem_id) ) ; 
if( ! eid) 
goto fail ; 


mixer — » count = elist. count; 

mixer —» fd = fd; 

elist space = mixer —> count; 

elist. pids = eid; 

/遍历 获得 各 个 控制 元 素 的 基本 信息 包括 ID 5755 snd. ctl. elem. id 中 的 信息 
if( ioctl ( fd, SNDRV_CTL_IOCTL_ELEM_LIST, &elist) <0) 








goto fail; 


/遍历 所 有 控制 元 素 
for( n 20;n < mixer —» count;n ++ ) | 
struct snd, etl. elem info * ei = mixer —> info + n; 
ei —» id. numid = eid| n]. numid; 
/获得 控制 元 素 的 详细 信息 ,主要 是 值 类 型 范围 等 . 
if(ioctl (fd, SNDRV_CTL_IOCTL_ELEM_INFO, ei) <0) 
goto fail; 











mixer —> ctl[ n ]. info = ei; 

mixer —> ctl[ n |. mixer = mixer; 

if( ei -» type == SNDRV. CTL. ELEM, TYPE ENUMERATED) | 
// 如 果 是 则 需要 继续 枚 举 


char * * enames = calloc( ei —> value. enumerated. items ,sizeof( char * ) ) ; 








if( ! enames ) 
goto fail; 
mixer — > ctl[ n ]. ename = enames; 
for(m 20;m < ei —> value. enumerated. items ; m ++ ) | 
memset( &tmp ,0 , sizeof( tmp) ) ; 
tmp. id. numid = ei -> id. numid ; 
tmp. value. enumerated. item 2 m; 
if( ioc ( fd, SNDRV. CTL, IOCTL, ELEM. INFO, &tmp) <0) 
goto fail ; 





enames[ m | = strdup( tmp. value. enumerated. name) ; 
if( lenames[ m] ) 


goto fail; 


free( eid) ; 
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fail s 


return mixer; 


/ * TODO: verify frees in failure case * / 
if( eid) 
free( eid) ; 
if( mixer) 
mixer close( mixer) ; 
else if( fd >=0) 
close( fd) ; 


return 0; 














从 代码 中 可 见 ， 主 要 的 操作 就 是 通过 相应 的 ioctl 命令 获得 所 有 控制 元 素 的 信息 。 对 应 








的 还 需要 读 取 和 写 入 控制 元 素 指 定数 据 的 接口 ， 细 节 如 下 : 
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int mixer ctl, get. value( struct mixer, ctl * ctl, unsigned int id) 


| 


struct snd_ctl_elem_value ev; 

int ret; 

// 控 制 元 素 中 包含 相应 的 数据 

if( ! ctl || (id >= ctl -> info -> count) ) 
return — EINVAL; 








memset( &ev ,0 , sizeof( ev) ) ; 

ev. id. numid = ctl -> info -> id. numid; 

// 读 取 控 制 元 素 的 所 有 数据 

ret = ioctl (ctl — mixer —> fd, SNDRV_CTL_IOCTL_ELEM_READ, &ev) ; 
if( ret <0) 


return ret; 








// 根 据 类 型 返回 相应 的 值 
switch( ctl -> info —> type) | 
case SNDRV. CTL ELEM, TYPE BOOLEAN: 


return | ! ev. value. integer. value| id ] ; 








case SNDRV CTL ELEM TYPE INTEGER: 





return ev. value. integer. value[ id | ; 


case SNDRV. CTL ELEM TYPE ENUMERATED: 





return ev. value. enumerated. item| id | ; 


case SNDRV CTL ELEM TYPE BYTES: 


return ev. value. bytes. data[ id | ; 





default : 
return — EINVAL; 


return 0; 


int mixer_ctl_set_value( struct mixer, ctl * ctl, unsigned int id, int value) 
| 
struct snd_ctl_elem_value ev; 
int ret; 
// 控 制 元 素 中 包含 相应 的 数据 
if( ! etl || (id >= ctl -> info -> count) ) 
return — EINVAL; 








memset( &ev ,0 , sizeof( ev) ) ; 

ev. id. numid = ctl —> info —> id. numid; 

// 读 取 控 制 元 素 所 有 的 值 

ret = ioctl ( ctl -> mixer -> fd, SNDRV_CTL_IOCTL_ELEM_READ, &ev) ; 
if(ret <0) 


return ret; 








// 根 据 类 型 修改 指定 的 值 

switch( ctl -> info —> type) | 

case SNDRV_CTL_ELEM_TYPE_BOOLEAN; 
ev. value. integer. value[ id] = ! ! value; 


break ; 





case SNDRV_CTL_ELEM_TYPE_INTEGER; 





ev. value. integer. value[ id] = value; 


break ; 


case SNDRV. CTL ELEM TYPE ENUMERATED: 





ev. value. enumerated. item| id | = value; 


break ; 


default : 
return — EINVAL; 
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B 


// 将 所 有 值 写 回 
return ioctl (ctl -> mixer —> fd, SNDRV_CTL_IOCTL_ELEM_WRITE, &ev) ; 














从 分 析 中 可 见 ， 控 制 元 素 中 的 内 容 读 写 也 是 通过 ioctl 来 进行 的 ， 不 过 内 容 是 一 个 整体 ， 





在 修改 的 时 候 需 要 先 读 取 ， 修 改 指定 内 容 后 再 写 回 。 
了 解 控制 流程 后 ， 还 需 了 解 pem 数据 流 的 操作 过 程 。 具 体 应 用 层 的 例子 如 下 : 














#include < stdio. h > 
#include < stdlib. h > 
#include " alsa/asoundlib. h" 


int main(int argc ,char * argv[ | ) 
| 
int 1; 
int ret; 
int bufL 128 ] ; 
unsigned int val; 
int dir =0; 
char * buffer; 
int size; 
snd_pcm_uframes_t frames; 
snd_pcm_uframes_t periodsize; 
//pem 设备 句柄 
snd. pem, t * playback handle; 
// 硬 件 信 息 和 pem 流 配置 


snd_pem_hw_params_t * hw. params; 





























FILE * fp =fopen(argv[ 1 ] ," rb") ; 
if(fp == NULL) 
return 0; 


fseek(fp, 100, SEEK, SET) ; 











// 打 开 pem, 最 后 一 个 参数 为 0 意味 着 标准 配置 
ret = snd_pem_open( &playback, handle," default" ,SND PCM, STREAM, PLAYBACK,0) ; 


// 分 配 snd. pem, hw. params, t 结构 体 


ret = snd. pem. hw. params, malloc( &hw. params ) ; 


// 初 始 化 hw. params 


ret = snd_pcm_hw_params_any(playback_handle ,hw_params ) ; 
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// 初 始 化 访问 权限 
ret = snd_pcm_hw_params_set_access( playback_handle,hw_params,SND_PCM_ACCESS_RW_IN- 
TERLEAVED) ; 








// 初 始 化 采样 格式 SND_PCM_FORMAT_U8,8 位 
ret = snd_pcm_hw_params_set_format( playback_handle,hw_params,SND_PCM_FORMAT_U8); 




















// 设 置 采样 率 ,如 果 硬 件 不 支持 设置 的 采样 率 将 使 用 最 接近 的 
val = 8000 ; 


ret = snd. pem. hw, params, set, rate near( playback, handle,hw. params , &val , &dir) ; 



































// 设 置 通道 数量 


ret = snd_pcm_hw_params_set_channels( playback_handle, hw_params ,2 ) ; 











frames = 32; 
periodsize = frames * 2; 


ret = snd. pem. hw, params, set, buffer size near( playback, handle,hw. params , &periodsize ) ; 





periodsize / 22; 


ret = snd, pem, hw, params, set, period. size near( playback, handle,hw. params , &periodsize ,0 ) ; 





// 设 置 hw. params 


ret = snd_pcm_hw_params( playback_handle, hw_params) ; 


/ * Use a buffer large enough to hold one period * / 


snd. pem, hw. params, get. period. size( hw. params , &frames , &dir) ; 





size = frames * 2;/ * 2 bytes/sample,2 channels * / 


buffer = (char * ) malloc( size) ; 


While 1) 
| 
ret = fread ( buffer ,1 ,size, fp) ; 


// 写 音频 数据 到 pem 设备 
while( ret = snd_pem_writei( playback, handle, buffer ,frames) <0) 
| 
usleep(2000 ) ; 
if(ret== — EPIPE) 
| 
/ * EPIPE means underrun * / 
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/完成 硬件 参数 设置 ,准备 好 设备 
snd_pcm_prepare( playback, handle) ; 

















} 
else if( ret <0) 
| 
fprintf(stderr, 
"error from writei; % s\n", 


snd_strerror( ret) ) ; 


| 
// 关 闭 pem 设备 句柄 
snd_pem_close( playback, handle) ; 





return 0; 


| 


这 里 的 例子 代码 重点 在 表述 操作 流程 ， 移 除了 相关 的 错误 处 理 部 分 ， 其 主要 流程 还 是 通 
过 ALSA 应 用 层 的 接口 进行 操作 ， 主 要 是 打开 、 设 置 ， 然 后 进行 数据 操作 。 

对 Android 框架 音频 设备 的 适 配 , Android 将 其 作为 HAL 层 的 模块 ， 相 应 的 模块 编译 
成 动态 库 ， 运 行 时 由 上 层 框 架 进 行 加 载 。 下 面 以 DM3730 Android 的 适 配 代 码 为 例 进行 





ipm 








说 明 。 
首先 是 HAL 模块 说 明 。 
struct audio module HAL MODULE INFO SYM = | 


. common - | 


. tag HARDWARE MODULE TAC, 








. module. api version = AUDIO MODULE API VERSION 0 1, 
. hal. api. version HARDWARE HAL API. VERSION, 


.id Z AUDIO HARDWARE MODULE ID, 
. name = " Rowboat audio HW HAL" , 
. author = "The Android Open Source Project" , 
. methods = &hal, module, methods , 
I 
is 


模块 说 明 中 ID 表示 是 音频 设备 的 适 配 模块 ， 操 作 接口 是 methods， 其 内 容 如 下 : 





static struct hw. module methods, t hal_module_methods = | 





. open = adev, open, 


l; 
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从 中 可 见 主 要 是 open 操作 接口 。 具 体 的 内 容 如 下 : 


static int adev_open( const hw, module, t * module ,const char * name, 


hw. device, t * * device) 


struct audio. device * adev ; 


int ret ; 


if( stremp( name, AUDIO HARDWARE INTERFACE) !=0) 
return — EINVAL; 


adev = calloc( 1 , sizeof( struct audio, device) ) ; 
if( ! adev ) 
return - ENOMEM ; 


adev -> hw. device. common. tag = HARDWARE. DEVICE TAG; 
adev — > hw, device. common. version = AUDIO DEVICE API. VERSION. 1 0; 
adev -> hw. device. common. module = (struct hw. module, t * ) module; 


adev — > hw. device. common. close = adev. close; 


adev —» hw. device. get. supported. devices = adev. get. supported. devices ; 
adev — > hw. device. init, check = adev, init, check ; 

adev — > hw. device. set, voice, volume = adev. set. voice, volume; 

adev — > hw. device. set, master. volume = adev, set, master. volume ; 
adev — > hw. device. set. mode = adev, set. mode; 

adev — > hw. device. set, mic, mute = adev, set, mic, mute; 

adev —» hw. device. get. mic, mute = adev. get mic, mute; 

adev -> hw. device. set. parameters = adev, set. parameters ; 

adev —» hw. device. get. parameters = adev. get. parameters ; 

adev —» hw. device. get. input, buffer size = adev. get. input, buffer size; 
adev —» hw. device. open. output, stream = adev, open. output, stream ; 
adev —» hw. device. close, output, stream = adev. close output, stream ; 
adev —» hw. device. open, input, stream = adev. open. input, stream ; 
adev —» hw. device. close input stream = adev. close input. stream; 


adev -> hw. device. dump = adev. dump; 


adev —> ar = audio, route. init( ) ; 


adev -> orientation = ORIENTATION. UNDEFINED; 
* device = &adev -> hw. device. common; 


return 0; 
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相关 的 操作 就 是 填充 系统 需要 的 接口 ， 这 些 接口 包括 控制 接口 和 数据 接口 。 在 数据 流 方 
Ifi Android 将 音频 流 中 的 playback 和 capture 作为 output stream 和 input stream， 这 里 对 应 
stream 的 open 和 close 操作 。 当 需要 打开 时 ， 相 应 的 stream 会 调用 open 接口 。 以 input stream 
操作 为 例 ， 看 一 下 其 详细 内 容 


static int adev_open_input_stream( struct audio_hw_device * dev, 
audio_io_handle_t handle, 
audio, devices t devices, 
struct audio. config * config, 


struct audio. stream, in * * stream, in) 


struct audio. device * adev = (struct audio, device * ) dev; 
struct stream in * in; 


int ret ; 
* stream. in = NULL; 


/ * Respond with a request for mono if a different format is given. * / 

if( config -> channel, mask !- AUDIO CHANNEL IN. MONO) | 
config —» channel, mask - AUDIO. CHANNEL IN. MONO; 
return — EINVAL; 


in = (struct stream, in * ) calloc( 1 ,sizeof( struct stream, in) ) ; 
if( lin) 
return - ENOMEM ; 


in — > stream. common. get_sample_rate = in get sample rate; 





in — > stream. common. set. sample. rate = in set sample rate; 





in — > stream. common. get. buffer size = in get. buffer size; 





in —> stream. common. get. channels = in. get. channels; 

in — > stream. common. get. format = in. get. format ; 

in — > stream. common. set, format = in, set, format ; 

in —> stream. common. standby = in, standby ; 

in —> stream. common. dump = in dump; 

in —> stream. common. set, parameters = in set parameters ; 
in — > stream. common. get. parameters = in get parameters ; 


in —> stream. common. add, audio, effect = in, add, audio, effect ; 





in 一 > stream. common. remove, audio, effect = in. remove, audio, effect ; 
in —> stream. set. gain = in set gain; 
in —> stream. read = in, read; 


in — > stream. get. input, frames lost = in get input frames lost; 
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in —» dev = adev; 
in —> standby = true; 


in — > requested, rate = config -> sample, rate ; 


in —> pem, config = &pem. config in;/ * default PCM config * / 


* stream in = Win —> stream; 
return 0; 


| 


其 中 仍 是 接口 的 设置 ， 但 可 见 其 中 的 设置 基本 与 pem 相关 的 参数 一 致 ， 实 际 的 适 配 就 


是 完成 以 上 的 接口 函数 。 














以 上 具体 的 接口 无 论 是 控制 接口 还 是 数据 接口 都 会 通过 Android 提供 Tiny ALSA 来 实现 


相应 的 功能 ，Tiny ALSA 实际 是 ALSA 应 用 层 库 的 简化 。 适 配 本 身 就 是 按照 设备 具体 的 情况 





进行 控制 流 和 数据 流 接口 的 实现 。 


6.3.4 TI 芯片 音频 驱动 相关 实现 详解 





实际 音频 驱动 的 分 析 会 以 DM3730 的 相关 驱动 为 例 进行 说 明 。 主 要 以 ASoC 中 的 各 个 模 


块 进行 介绍 。 
1. machine 模块 
首先 来 看 一 下 初始 化 部 分 : 


//machine 相关 的 初始 化 函数 
static int __init omap3evm_soc_init( void) 
| 


int ret; 


if( ! machine_is_omap3evm( ) ) 
return - ENODEV; 
pr. info( " OMAP3 EVM SoC init Wn" ) ; 














// 这 里 分 配 并 注册 platform. device 是 因为 ASoC core H 
//soc—audio driver, 其 中 probe 会 注册 soc_card 








FR 


omap3evm, snd, device = platform. device alloc( " soc- audio" , - 1) ; 


if( ! omap3evm, snd. device) | 


printk( KERN, ERR "Platform device allocation failed Wn" ) ; 


return - ENOMEM ; 


// 设 置 soc. card 并 加 入 platform. deivce ,以 便 soc— audio 
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/人 /进行 实际 的 注册 soc. card 操作 

platform_set_drvdata( omap3evm_snd_device , &snd_soc_omap3evm) ; 
ret = platform_device_add( omap3evm_snd_device) ; 

if( ret) 


goto errl ; 
return 0; 
erri : 
printk( KERN, ERR " Unable to add platform device Wn" ) ; 


platform, device, put( omap3evm, snd, device) ; 


return ret ; 








其 中 涉及 的 主要 部 分 就 是 snd_soc_omap3evm， 包含 了 物理 连接 的 属性 ， 具 体内 容 
如 下 : 


// 具 体 的 CPU dai/codec/codec dai/platform 之 间 的 link 说 明 
// 说 明 具 体 用 哪些 CPU dai/codec/codec dai/platform. 
static struct snd_soc_dai_link omap3evm dai[ | = | 


| 















































. name ="TWL4030"， 

. stream_name ="TWL4030"， 

// FH omap3 mcbsp2 

. cpu_dai_name ="omap — mcbsp - dai. 1" , 
. codec. dai name z"twl4030 — hifi" , 

. platform. name =" omap - pem — audio" , 

. codec. name =" twl4030 - codec" , 

. ops = &omap3evm. ops, 


il? 
| 


/ * Audio machine driver * / 
//soc card 的 说 明 ,最 后 在 ALSA 中 为 card 
static struct snd_soc_card snd_soc_omap3evm = | 
. name =" omap3evm" , 
. dai link = omap3evm dai, 
. num links = ARRAY SIZE( omap3evm_dai) , 
i 


操作 接口 omap3evm_ops 主要 就 是 硬件 参数 的 接口 ， 详 细 分 析 如 下 : 
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// 该 接口 主要 是 pem 使 














static int omap3evm_hw_params( struct snd_pcm_substream * substream, 


| 


struct snd_pcm_hw_params * params) 


struct snd, soc. pem, runtime * rtd = substream 一 > private_data; 
struct snd_soc_dai * codec, dai = rtd -> codec, dai ; 
struct snd. soc. dai * cpu. dai = rtd -> cpu, dai; 


int ret ; 


/ * Set codec DAI configuration * / 
// 设 置 codec dai HVS 格式 
ret = snd, soc, dai. set, fmt( codec, dai, SND. SOC. DAIFMT I2S | 
SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM) ; 
if( ret <0) | 
printk( KERN, ERR "Can t set codec DAI configuration Wn" ) ; 


return ret ; 











/ * Set cpu DAI configuration * / 
// 设 置 CPU dai 为 从 TS 格式 
ret = snd_soc_dai_set_fmt( cpu_dai,SND_SOC_DAIFMT_I2S 
| SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM) ; 
if( ret <0) | 
printk( KERN, ERR "Can t set cpu DAI configuration n" ) ; 











return ret; 


/ ** Set the codec system clock for DAC and ADC * / 
// 设 置 clks 
ret = snd_soc_dai_set_sysclk( codec_dai,0 ,26000000 , SND_SOC_CLOCK_IN) ; 
if( ret <0) | 
printk( KERN, ERR " Caii t set codec system clock\n" ) ; 


return ret ; 


return 0; 


从 整体 上 来 看 machine 部 分 主要 负责 整体 连接 的 设 定 ， 并 不 涉及 太 多 的 操作 ， 


必 , 用 于 设置 machine 的 CPU dai ,codec dai 的 参数 并 保持 一 致 . 


具体 的 操 


作 也 是 在 整体 上 保证 系统 中 各 个 接口 的 一 致 性 。 而 ALSA 框架 为 了 保证 这 种 一 致 o 





供 


了 对 处 理 器 侧 dai 接口 以 及 codec 侧 dai 接口 进 
函数 来 完成 对 应 的 操作 的 。 


行 操作 的 函数 ，machine 模块 就 是 通 


这 些 


495 


2. platform 模块 

该 模块 主要 是 使 用 DMA 进行 数据 传输 ， 下 面 进行 具体 分 析 。 

首先 该 模块 要 提供 snd_soc_platform_driver， 并 在 相应 的 platform device 被 probe 时 注册 ， 
详细 的 信息 如 下 : 











// ASoC platform 接口 主要 是 CPU DMA 的 接口 


static struct snd_soc_platform_driver omap_soc_platform = | 


. ops = &omap. pem, ops, 
. pem, new = omap. pem. new, 
. pem. free = omap. pem. free dma buffers, 


l; 





主要 的 部 分 是 各 种 操作 接口 omap_pem_ops 以 及 创建 pem 时 初始 化 的 pem_new 接口 
omap_pcm_new。 对 于 omap. pem, new 的 细节 如 下 : 


// 创 建 pcm 的 接口 ,DMA 相关 的 new 操作 主要 是 为 stream 分 配 DMA buffer 空间 


static int omap. pem, new( struct snd, card * card , struct snd_soc_dai * dai, 








struct snd_pem * pem) 


int ret 20; 


if( ! card -> dev -> dma, mask) 
card -> dev -> dma, mask = &omap. pcm. dmamask ; 
if( ! card -> dev -> coherent, dma, mask ) 


card -> dev -> coherent. dma, mask = DMA, BIT MASK(64) ; 


// 为 相应 的 playback/capture stream 分 配 DMA buffer 

if( dai -> driver -> playback. channels min) | 

ret = omap. pem, preallocate. dma, buffer( pem, SNDRV. PCM. STREAM, PLAYBACK ) ; 
if( ret) 


goto out; 


if( dai —» driver -> capture. channels, min) | 
ret = omap. pem, preallocate dma, buffer( pem, SNDRV, PCM, STREAM, CAPTURE) ; 
if( ret) 


goto out ; 


out : 


return ret ; 
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主要 是 分 配 空间 ， 而 omap_pem_ops 的 内 容 如 下 : 





// pem 的 操作 接口 
static struct snd_pem_ops omap_pcm_ops = | 
. open = omap pem open, 
. close = omap. pem. close , 
. ioctl -snd pem, lib. ioctl , 
. hw. params = omap. pem. hw. params, 
. hw. free = omap. pem hw. free, 
. prepare = omap. pem. prepare, 
. trigger = omap. pem, trigger, 
. pointer = omap pem pointer, 
. mmap = omap pem mmap, 


bs 





这 里 主要 是 各 种 操作 接口 ， 下 面 对 几 个 接口 进行 分 析 : 


//pem open 是 DMA 的 接口 ,主要 分 配 驱 动 相 关 的 runtime 的 管理 实体 
// 包 括 DMA channel 和 DMA 属性 等 
static int omap. pem, open( struct snd_pem_substream * substream ) 


| 


i 








struct snd, pem, runtime * runtime = substream — > runtime; 
struct omap. runtime. data * prtd ; 


int ret ; 


// 设 置 pem, hardware 限制 


snd. soc. set, runtime hwparams( substream , &omap. pem, hardware) ; 


/ * Ensure that buffer size is a multiple of period size * / 
// 设 置 periods 必须 为 整数 的 限制 
ret = snd_pem_hw_constraint_integer( runtime ,SNDRV_PCM_HW_PARAM_PERIODS) ; 
if(ret <0) 











goto out; 





// 分 配 相应 的 runtime 管理 实体 并 初始 化 
prtd = kzalloc( sizeof( * prtd) , GFP. KERNEL) ; 
if(prtd==NULL) | 

ret = - ENOMEM; 


goto out; 





// 初 始 化 相应 的 spin lock 
spin_lock_init( &prtd —» lock) ; 
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runtime —> private data = prtd; 


out: 


return ret; 

















//pem 设置 hw 参数 的 接口 ,主要 是 申请 DMA ,这 里 保证 DMA 的 设置 
上 和 dai 具体 接口 的 设置 分 开 , 保 证 DMA 设置 的 独立 性 . 


static int omap_pcm_hw_params( struct snd_pem_substream * substream , 









































struct snd_pem_hw_params * params) 


struct snd_pcm_runtime * runtime = substream —> runtime; 
struct snd, soc. pem, runtime * rtd = substream —> private_data; 
struct omap. runtime data * prtd = runtime — > private, data; 


struct omap. pem. dma, data * dma, data; 


int err 20; 


a 








// 该 函数 要 将 dai 的 DMA 属性 转换 为 pem runtime 使 用 的 DMA 属性 
// dai 管理 的 通常 是 物理 DMA 属性 信息 runtime 管理 的 是 动态 
// 分 配 的 logical channel 等 信息 . 







































































// 首 先 获得 CPU dai 设置 的 pem 所 带 的 DMA 管理 信息 
// 相 关 的 信息 是 在 CPU dai 的 hw_params 中 设置 的 ， 

// 按 照 soc — core 的 执行 逻辑 先 执行 CPU dai 的 hw_params 
// 然 后 执行 DMA 的 hw_params dai 的 hw_params 主要 是 进行 
// 基 本 的 传输 属性 的 设置 包括 dai 使 用 的 dma_req 信号 

// 地 址 sync 方式 等 


dma_data = snd_soc_dai_get_dma_data( rtd -> cpu, dai ,substream) ; 










































































/ * return if this is a bufferless transfer e. g. 
* codec < ——» BT codec or GSM modem - - lg FIXME * / 
if( ! dma, data) 


return 0; 


// 设 置 substream 的 DMA buffer, 3X J& buffer 应 该 是 在 pem. new 时 分 配 的 


snd. pem, set. runtime, buffer( substream , &substream -> dma, buffer) ; 





// 设 置 pem Tii] DMA buffer 占用 的 bytes ,为 对 应 用 层 映 射 mmap 准备 
// T£ dai 的 dai, startup 接口 中 会 对 SNDRV_PCM_HW_PARAM_BUFFER_SIZE 
// 对 于 dai 的 fifo size 进行 修正 从 而 保证 这 里 有 合适 的 size 值 。dai_startup 会 
// 在 pcem_open 中 调用 。 而 在 hw_params 的 时 候 会 根据 之 前 pem. open 时 add 的 规则 
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/重新 提炼 传人 的 参数 保证 符合 硬件 的 属性 ,这 是 应 该 会 调整 相应 的 值 


runtime — > dma_bytes = params_buffer_bytes( params ) ; 











if( prtd -> dma, data) 
return 0; 
// 将 dai 管理 的 DMA 属性 关联 到 runtime FLAK Jes T 
prid —» dma, data = dma, data; 
// 请 求 DMA channel 





























err = omap_request_dma( dma_data -> dma_req, dma_data -> name, 
omap. pem. dma, irq,substream , &prtd -> dma_ch) ; 
if( lerr) | 
J * 
* Link channel with itself so DMA doesn t need any 
* reprogramming while looping the buffer 
*/ 
//DMA channel link 到 上 自己 ,保证 DMA 的 持续 传输 . 
// 这 里 只 是 设置 link ,真正 link 的 enable 要 在 DMA start 才 开始 . 
omap_dma_link_lch(prtd -> dma_ch, prtd -> dma ch) ; 

















return err; 





// 对 应 于 pem 的 trigger 接口 ,主要 用 来 控制 状态 start stop suspend resume 等 
static int omap. pem, trigger( struct snd_pcm_substream * substream ,int cmd) 
| 

struct snd_pcm_runtime * runtime = substream —> runtime; 

struct omap_runtime_data * prtd = runtime — > private_data; 

struct omap. pem. dma, data * dma_data = prtd -> dma_data; 

unsigned long flags; 


int ret 20; 


spin, lock, irqsave( &prtd -> lock, flags) ; 
switch ( cmd) | 
case SNDRV. PCM, TRIGGER, START: 
case SNDRV. PCM, TRIGGER, RESUME: 
case SNDRV. PCM. TRIGGER, PAUSE RELEASE: 
prid -> period. index 20; 
/ * Configure McBSP internal buffer usage * / 
//DMA 开始 时 要 保证 可 以 触发 DMA request, 所 以 有 必要 设置 threshold 
if( dma_data — > set, threshold) 


dma, data —> set. threshold ( substream ) ; 
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//enable 相应 的 DMA 及 其 irq 
omap. start. dma( prtd -> dma_ch) ; 
break ; 


case SNDRV. PCM, TRIGGER, STOP: 
case SNDRV. PCM, TRIGGER, SUSPEND: 
case SNDRV. PCM. TRIGGER, PAUSE PUSH: 
// 停 止 相 关 的 操作 ,要 stop DMA 
prtd -> period. index = -1; 
omap. stop. dma( prtd -> dma, ch) ; 
break ; 
default; 
ret = — EINVAL; 
| 


spin_unlock_irqrestore( &prtd -> lock, flags ) ; 


return ret; 


| 





其 具体 的 细节 就 是 根据 需要 通过 ALSA pcm 接口 设置 参数 限制 ， 另 外 主要 的 工作 就 是 在 
相应 的 操作 接口 对 DMA 进行 设置 和 正确 地 操作 。 

3. 处 理 器 侧 dai 模块 

DM3730 中 音频 流 的 接口 设备 是 McBSP (multichannel buffered serial port) ， 其 可 以 支持 
各 种 音频 流 的 传输 方式 如 (PS, TCM) 等 ， 实 际 的 代码 中 就 是 要 根据 参数 的 格式 对 硬件 进 
行 正确 的 设置 。 对 于 硬件 McBSP 的 框架 结构 如 图 6-17 所 示 。 

图 6-17 引 自 《DM3730 芯片 手册 》 中 第 3096 页 框图 。 在 dai 模块 中 主要 通过 设置 其 中 
左上 的 寄存 器 组 来 完成 ， 而 DMA 则 是 通过 操作 DRR 和 DXR 寄存 器 来 完成 数据 的 读 写 。 

下 面 来 看 看 dai 相关 的 实现 细节 。 对 于 驱动 主要 是 注册 dai 接口 的 驱动 ， 其 细节 如 下 : 

















//CPU dai 的 driver 说 明 
static struct snd_soc_dai_driver omap_mcbsp_dai = 
| 
. probe = mcbsp_dai_probe, 
. playback = | 
//playback 的 能 力 说 明 
. channels_min =1, 
. channels max 216, 
. rates = OMAP MCBSP RATES, 
. formats = SNDRV. PCM, FMTBIT S16 LE | SNDRV. PCM, FMTBIT S32 LE, 








E 
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图 6-17 McBSP 框架 


. capture = | 
//capture 的 能 力 说 明 
. channels_min 21, 
. channels, max 216, 
. rates = OMAP MCBSP RATES, 
. formats = SNDRV, PCM, FMTBIT S16 LE | SNDRV. PCM, FMTBIT S32 LE, 
e 
/操作 接口 
. ops = &mcbsp_dai_ops, 


可 见 主要 包括 数据 能 力 和 操作 接口 。 操 作 接 口 的 细节 如 下 : 


// 这 里 是 重要 的 dai ops 集合 


static struct snd_soc_dai_ops mcbsp. dai ops = | 
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. startup = omap. mcbsp. dai. startup, 





. shutdown = omap. mcbsp. dai. shutdown, 

. trigger = omap. mcbsp. dai trigger, 

. delay = omap. mcbsp. dai. delay, 

. hw. params = omap. mcbsp. dai hw, params , 

. set. fmt = omap. mcbsp. dai. set, dai fmt, 

. set. clkdiv = omap. mcbsp. dai, set, clkdiv, 

. set, sysclk = omap. mcbsp. dai set, dai sysclk, 





E 
下 面 对 主 要 的 接口 进行 分 析 : 


//pem 下 进行 hw 参数 设置 的 接口 ,其 中 的 操作 主要 是 :1. 设置 McBSP 相关 
// 的 DMA 属性 ,为 CPU DMA 提供 相应 的 配置 数据 ;2. 进行 McBSP 

// 接 口 的 必要 寄存 髓 设置 ,这 里 主要 是 对 word length 和 frame size 涉及 音频 
// 应 用 层 参 数 的 最 后 设置 ,加 上 之 前 dai 的 set_dai_fmt 的 format 基本 设置 后 
// 统 一 通过 plat - omap 下 McBSP 提供 的 config 接口 设置 寄存 器 


static int omap_mcbsp_dai_hw_params( struct snd_pcm_substream * substream, 




















struct snd_pcm_hw_params * params, 


struct snd_soc_dai * cpu, dai) 


struct omap. mebsp. data * mcbsp_data = snd, soc, dai, get. drvdata( epu, dai) ; 
struct omap. mcbsp. reg. cfg * regs = &mcbsp. data —> regs; 

struct omap. pem. dma, data * dma, data; 

int dma, bus, id = mcbsp. data -> bus. id; 

int wlen, channels, wpf, sync. mode = OMAP DMA, SYNC ELEMENT; 

int pkt. size 20; 

unsigned long port; 


unsigned int format , div , framesize , master; 


// 首 先 获得 基本 的 MeBSP 的 DMA 的 配置 静态 空间 


dma_data = &omap_mcbsp_dai_dma_params[ cpu. dai -> id ] [ substream —> stream | ; 

















if( cpu, class is omapl( ) ) | 
dma = omapl, dma. reqs[ bus, id ] | substream —> stream | ; 
port = omapl, mcbsp. port[ bus, id | [ substream —> stream ] ; 
| else if( cpu. is. omap2420( ) ) | 
dma = omap24xx_dma_reqs| bus, id | [ substream —> stream | ; 
port = omap2420. mcbsp. port[ bus. id | [ substream —> stream ] ; 
| else if( cpu. is. omap2430( ) ) | 
dma = omap24xx_dma_reqs| bus, id | [ substream —> stream | ; 
port = omap2430. mcbsp. port[ bus, id | [ substream —> stream | ; 
| else if( cpu, is. omap343x( ) ) | 
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dma = omap24xx_dma_reqs| bus, id | [ substream —> stream | ; 


port = omap34xx_mcbsp_port[ bus, id | [ substream —> stream | ; 


| else} 
return - ENODEV; 
} 
// 设 置 DMA HY word length 
switch ( params, format( params) ) | 
case SNDRV. PCM, FORMAT SI6 LE: 
dma, data -> data type = OMAP DMA DATA TYPE S16; 
wlen 216; 
break ; 
case SNDRV. PCM, FORMAT $32. LE: 
dma, data -> data type = OMAP DMA . DATA, TYPE $32; 
wlen 232; 
break ; 
default : 
return — EINVAL; 








} 
if( cpu, is. omap343x( ) ) | 





// 这 里 提供 给 CPU DMA 进行 dai threshold JE EB E , Heil 
// 发 生变 化 特别 是 start 时 threshold 应 该 进行 相应 的 设置 . 























//CPU DMA 的 trigger 接口 会 调用 该 接口 进行 操作 . 
dma, data -> set. threshold = omap_mcbsp_set_threshold ; 





E DMA 状态 


/ * TODO; Currently, MODE ELEMENT == MODE FRAME * / 


if( omap. moebsp. get. dma, op. mode( bus, id) 
== MCBSP DMA, MODE THRESHOLD) | 


int period words , max, thrsh ; 





period, words = params, period, bytes( params )/ ( wlen/8) ; 


if( substream -> stream == SNDRV. PCM. STREAM  PLAYBACK ) 


max, thrsh = omap. mcbsp. get. max tx, threshold( 





mcebsp. data -> bus. id) ; 
else 


max, thrsh = omap. mcbsp. get. max rx, threshold( 





mcebsp. data -> bus. id) ; 
J * 


* If the period contains less or equal number of words, 


* we are using the original threshold mode setup: 

* McBSP threshold =sDMA frame size = period_size 
* Otherwise we switch to sDMA packet mode: 

* McBSP threshold = sDMA packet size 


* sDMA frame size = period size 
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ay 

// 如 果 一 个 period 包含 的 McBSP word iit T [B] [Ei , SAn UEH 

//DMA 和 dai 同步 的 问题 主要 是 硬件 接口 要 求 一 次 传输 为 fifo BJE 

// 而 逻辑 上 无 法 满足 DMA 一 个 中 断 传 输 period 大 小 的 数据 。 这 就 要 求 

// 进 行 DMA packet sync 操作 修正 相应 的 packet 值 ,保证 DMA 的 正确 传输 和 
// 正 确 中 断 . 


if( period_words > max_thrsh) | 








int divider =0; 


/ok 
* Look for the biggest threshold value, which 
* divides the period size evenly. 
*/ 
divider = period words/max, thrsh ; 
if( period. words 96 max, thrsh) 
divider ++ ; 
while( period. words % divider && 
divider < period. words ) 
divider ++ ; 
if( divider == period_words ) 
return — EINVAL; 


pkt_size = period_words/ divider; 
sync_mode = OMAP_DMA_SYNC_PACKET; 
| else} 
// 这 里 period 包含 的 数据 大 小 小 于 threshold 
// 即 frame size 满足 fifo threshold ,只 要 设置 sync_frame 即 可 
sync_mode = OMAP_DMA_SYNC_FRAME; 























//DMA 的 其 他 属性 设置 


dma_data -> name = substream -> stream ? " Audio Capture" ; " Audio Playback" ; 





dma, data -> dma req = dma; 

dma, data —> port, addr = port; 

// F til fIl hardware sync mode 相关 
dma, data -> sync, mode = sync, mode ; 


dma, data -> packet, size = pkt, size; 











// 设 置 cpu, dai 的 DMA 属性 ,以 便 后 续 CPU DMA hw. param 使 用 . 


snd_soc_dai_set_dma_data( cpu. dai , substream ,dma_data ; 
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// 相 应 的 McBSP 接口 必须 首次 设置 ,否则 直接 返 
if( mebsp_data — > configured ) | 





inj 








/ * McBSP already configured by another stream * / 


return 0; 


// 下 面 是 基本 的 format 设置 , 主要 包括 word frame 和 phase 的 设置 














// 男 外 注意 对 于 format 的 整体 设置 包括 下 面 几 个 部 分 











//SND_SOC_DAIFMT_FORMAT_MASK;SND_SOC_DAIFMT_CLOCK_MASK 











//SND_SOC_DAIFMT_INV_MASK;SND_SOC_DAIFMT_MASTER_MASK 





format = mcbsp. data -> fmt & SND_SOC_DAIFMT_FORMAT_MASK; 


wpf = channels = params_channels( params ) ; 
if(channels ==2 &&( format ==SND_SOC_DAIFMT_I2S || 
format == SND_SOC_DAIFMT_LEFT_J) ) | 
/ * Use dual — phase frames * / 
// WARE PS 格式 , 则 设置 dual — phase 
regs 一 > rcr2 | = RPHASE; 
regs —» xcr2 |= XPHASE; 
/ * Set 1 word per( McBSP) frame for phasel and phase2 * / 
// 注 意 dual — phase 模式 设置 frame 的 channel 必须 为 1 
// 但 是 word size 可 以 两 个 phase 不 同 








wpf ——; 
regs —» rcI2 | = RFRLEN2 (wpf -1); 
regs 一 > xcr2 | = XFRLEN2 (wpf - 1) ; 


// 设 置 frame 的 channel 数 
regs —» rcrl |=RFRLENI (wpf -1); 
regs 一 > xcrl |=XFRLENI (wpf -1); 





// 设 置 word length 

switch ( params_format( params) ) | 

case SNDRV. PCM, FORMAT SI6 LE: 
/ * Set word lengths * / 


regs -> rer2 | = RWDLEN2(OMAP_MCBSP_WORD_16) ; 
regs —> rerl | = RWDLENI ( OMAP. MCBSP. WORD. 16) ; 
regs ->xer2 | = XWDLEN2(OMAP_MCBSP_WORD_16) ; 
regs -> xcrl | = XWDLENI ( OMAP. MCBSP. WORD. 16) ; 
break; 


case SNDRV. PCM. FORMAT $32 LE: 
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/ * Set word lengths * / 


a |  RWDLEN2( OMAP. MCBSP. WORD_32) ; 
uero | = RWDLENI ( OMAP. MCBSP. WORD 32) ; 
n m) | = XWDLEN2( OMAP. MCBSP. WORD. 32) ; 
uestes | = XWDLENI ( OMAP. MCBSP. WORD. 32) ; 
break ; 

default; 


/ * Unsupported PCM format * / 
return — EINVAL; 


/ * In McBSP master modes, FRAME(i. e. sample rate) is generated 
* by. counting BCLKs. Calculate frame size in BCLKs * / 
// 检 查 是 master 还 是 slave , WER codec 的 bit clock 和 frame sync 都 做 slave 即 
//SND. SOC. DAIFMT. CBS CFS 则 McBSP 做 master 
master = mcebsp. data —» fmt & SND. SOC. DAIFMT MASTER, MASK ; 
// F É frame size 的 值 主要 是 看 占 多 少 bit clocks 
if( master == SND_SOC_DAIFMT_CBS_CFS) | 
// *4 McBSP 做 master 的 时 候 ,frame size 应 该 通过 bit clock 计算 
// div 为 分 频 的 除数 
div = mebsp. data -> clk div ? mcbsp_data -> clk div ; 1; 
// 根 据 采样 率 算出 frame 占 多 少 bit clock 


framesize = (mcbsp_data -> in_freq/div ) /params_rate (params ) ; 






































if( framesize < wlen * channels) | 
printk( KERN, ERR " 96s; not enough bandwidth for desired rate and " 
"channels\n" ，_ fune. ); 
return — EINVAL; 
| 
| else 
//slave 设备 frame size 直接 word length x channel 数目 即 可 


framesize = wlen * channels; 











// 38 Jt frame size 计算 出 来 要 根据 相应 的 值 填 FS 信和 号 间隔 周期 
// VA FS 信和 号 的 宽度 。 相 应 的 寄存 器 值 + 1 才 是 实际 的 
上 /周期 ,所 以 填写 寄存 器 的 时 候 都 - 1. 


/ * Set FS period and length in terms of bit clock periods * / 




















switch ( format) | 

case SND SOC. DAIFMT DS. 

case SND SOC, DAIFMT LEFT J: 
//fs 周期 间隔 frame size 

















regs — > srgr2 | = FPER( framesize - 1) ; 
// 这 里 是 2 phase mode, 所 以 fs 宽度 为 frame size/2 
regs —» srgrl | =FWID( (framesize >>1) -1); 
break ; 

case SND SOC. DAIFMT DSP A: 

case SND. SOC. DAIFMT DSP B; 
//fs 周期 间隔 frame size 




















regs — > srgr2 | = FPER( framesize - 1) ; 
//fs 宽度 只 要 1 bit clock 即 可 

regs —» srgrl |=FWID(0) ; 

break ; 


// 至 此 pem 的 hw_params 调用 已 经 进行 的 所 有 的 MeBSP 接口 
// 的 配置 ,所 以 可 以 进行 实际 的 McBSP 寄存 器 的 config 操作 
omap. mcbsp. config( bus. id, &mcbsp. data —> regs) ; 

// 记 录 word length 并 标记 已 经 进行 实际 硬件 接口 config 


mcbsp. data —» wlen = wlen; 











mcbsp. data -> configured = 1; 


return 0; 


// 下 面 的 函数 主要 是 对 与 dai 接口 设置 format ,应 该 和 codec dai 的 format — $t . 
// 这 里 format 主要 是 基本 的 音频 传输 协议 格式 包括 下 面 几 个 方面 : 
//SND_SOC_DAIFMT_FORMAT_MASK 基本 格式 比如 S pem 等 
//SND_SOC_DAIFMT_CLOCK_MASK clock 设置 
//SND_SOC_DAIFMT_INV_MASK 信和 号 高 低 有 效 主 要 是 极 性 设置 
//SND_SOC_DAIFMT_MASTER_MASK 主 从 设置 


static int omap_mcbsp_dai_set_dai_fmt( struct snd_soc_dai * cpu_dai, 
























































unsigned int fmt) 


struct omap_mcbsp_data * mcbsp_data = snd_soc_dai_get_drvdata( cpu. dai) ; 


struct omap_mcbsp_reg_cfg * regs = &mcbsp_data —> regs; 


unsigned int temp_fmt = fmt; 


if( mebsp. data — > configured ) 


return 0; 


/保存 上 层 的 format 设置 到 McBSP 的 管理 结构 中 
mcbsp. data —> fmt = fmt; 
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memset (regs ,0 , sizeof( * regs) ) ; 

/ * Generic McBSP register settings * / 

// 基 本 的 McBSP 配置 ,设置 发 送 sync error 中 断 
//F BiE McBSP 一 直 运 行 


























regs —» spcr2 |=XINTM(3) | FREE; 
// 设 置 接收 receive sync error rH pjr 
regs 一 > spcrl |= RINTM(3); 


/ * RFIG and XFIG are not defined in 34xx * / 

if( ! cpu, is; omap34xx( ) ) | 
regs —» rcr2 | = RFIG; 
regs — > xcr2 | = XFIG; 

| 

if(cpu_is_omap2430( ) || epu. is omap34xx( ) ) | 
// i, DXENDLY -When McBSPi. MCBSPLP. SPCRI, REG[ 7] DXENA bit is 
//set to one ,this field selects the added delay 
//XDMAEN - Transmit DMA Enable bit 主要 是 DMA req 信号 的 使 能 
// XDISABLE - disable transmit 
regs ->xccr = DXENDLY(1) | XDMAEN | XDISABLE; 
// 设 置 receive HY full, cycle 表示 在 fs 和 data 在 belk 的 相同 边沿 采样 
//RDMAEN - Receive DMA Enable bit 主要 是 DMA req 信号 的 使 能 
//RDISABLE - disable receive 
regs —> reer = RFULL_CYCLE | RDMAEN | RDISABLE; 











// 根 据 要 设置 的 format 进行 基本 的 全 后 的 data 延 时 设置 
// 以 及 信号 极 性 belk REF AM fs 极 性 设置 
//Normal BCLK + FS; FS active low. TX data driven on falling edge of bit clock 
//and RX data sampled on rising edge of bit clock. 
// 对 于 音频 format 的 详细 信息 见 tm21. 2. 4 
switch( fmt & SND_SOC_DAIFMT_FORMAT_MASK) | 
case SND SOC. DAIFMT DS. 
/ * ] — bit data delay * / 





























regs —» rcr2 |= RDATDLY(1) ; 
regs 一 > xcr2 |=XDATDLY(1) ; 
break ; 


case SND_SOC_DAIFMT_LEFT_J: 
/ * 0 — bit data delay * / 





regs —» rcr2 |= RDATDLY(0) ; 
regs 一 > xcr2 |=XDATDLY(0) ; 
regs 一 > spcrl | =RJUST(2); 


/ * Invert FS polarity configuration * / 
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//fs 信号 极 性 反 
temp. fmt ^= SND. SOC, DAIFMT. NB IF; 
break ; 

case SND_SOC_DAIFMT_DSP_A; 
/ * l — bit data delay * / 
regs —» rcr2 | x RDATDLY(1) ; 
regs —> xcr2 |=XDATDLY(1) ; 








/ * Invert FS polarity configuration * / 
//fs 信号 极 性 反 
temp. fmt ^= SND. SOC DAIFMT NB IF; 
break ; 

case SND SOC DAIFMT DSP B: 
/ * 0 — bit data delay * / 
regs —» rcr2 |= RDATDLY(0) ; 
regs 一 > xcr2 |=XDATDLY(0) ; 








/ * Invert FS polarity configuration * / 
//fs 信和 号 极 性 反 
temp. fmt ^= SND. SOC DAIFMT NB IF; 
break ; 

default; 
/ * Unsupported data format * / 
return — EINVAL; 





// flt master/ slave 的 设置 























switch (fmt & SND SOC. DAIFMT MASTER. MASK) | 





case SND SOC. DAIFMT CBS CFS; 





/ ** McBSP master. Set FS and bit clocks as outputs * / 


/ / flt master , fs FU clk 信号 输出 
regs —» pcr0 | s FSXM | FSRM | 
CLKXM | CLKRM; 
/ * Sample rate generator drives the FS * / 
/产生 采样 信号 
regs 一 > srgr2 |= FSGM; 
break; 
case SND_SOC_DAIFMT_CBM_CFM; 
/ * McBSP slave * / 
break ; 
default : 





/ * Unsupported master/slave configuration * / 


return — EINVAL; 
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/ * Set bit clock( CLKX/CLKR) and FS polarities * / 
// WERE belk 信号 和 人 信号 极 性 
switch( temp. fmt & SND_SOC_DAIFMT_INV_MASK) | 
case SND. SOC. DAIFMT NB NF: 
J * 
* Normal BCLK + FS. 
* FS active low. TX data driven on falling edge of bit clock 








* and RX data sampled on rising edge of bit clock. 
*/ 
// ATE fs Fl clk 极 性 设置 都 设 为 nb + nf 
regs — > pcr0 |=FSXP | FSRP | 
CLKXP | CLKRP; 





break ; 
case SND_SOC_DAIFMT_NB_IF: 
//clk 极 性 设置 设 了 为 nb 
regs -> pcr0 |= CLKXP | CLKRP; 
break ; 
case SND_SOC_DAIFMT_IB_NF: 
//fs 极 性 设置 设 了 为 of 
regs —> pcr0 | = FSXP | FSRP; 
break ; 
case SND_SOC_DAIFMT_IB_IF; 
/人 /都 不 设 为 让 + 让 
break ; 
default; 
return — EINVAL; 
































return 0; 


// PTS PRICE EJ]; dai 接口 设置 format ,应 该 和 codec dai 的 format 一 致 . 





























// 这 里 format 主要 是 基本 的 音频 传输 协议 格式 包括 下 面 几 个 方 男 
//SND_SOC_DAIFMT_FORMAT_MASK 基本 格式 比如 PS pem 等 
//SND_SOC_DAIFMT_CLOCK_MASK clock 设置 
//SND_SOC_DAIFMT_INV_MASK 信号 高 低 有 效 主要 是 极 性 设置 
//SND_SOC_DAIFMT_MASTER_MASK 主 从 设置 


static int omap_mcbsp_dai_set_dai_fmt( struct snd_soc_dai * cpu_dai, 


























unsigned int fmt) 


struct omap_mcbsp_data * mcbsp_data = snd_soc_dai_get_drvdata( cpu, dai) ; 
struct omap_mcbsp_reg_cfg * regs = &mcbsp_data —> regs; 


unsigned int temp_fmt = fmt; 


if( mebsp_data — > configured ) 


return 0; 


// 保 存 上 层 的 format 设置 到 McBSP 的 管理 结构 中 
mcbsp. data —> fmt = fmt; 





memset( regs ,0 , sizeof( * regs) ) ; 

/ * Generic McBSP register settings * / 

// 基 本 的 McBSP 配置 ,设置 发 送 sync error FUSE 
//Jf Bik MeBSP — E3817 























regs —» spcr2 |=XINTM(3) | FREE; 
// 设 置 接收 receive sync error "P Wr 
regs 一 > spcrl | =RINTM(3) ; 


/ * RFIG and XFIG are not defined in 34xx * / 

if( | cpu, is; omap34xx( ) ) | 
regs — > rcr2 | =RFIG; 
regs —» xci2 |=XFIG; 

| 

if(cpu_is_omap2430( ) || cpu_is_omap34xx( ) ) | 
// 设 置 DXENDLY -When McBSPi. MCBSPLP. SPCRI, REG[ 7] DXENA bit is 
//set to one ,this field selects the added delay 
//XDMAEN - Transmit DMA Enable bit 主要 是 DMA req 信号 的 使 能 
// XDISABLE - disable transmit 
regs —» xcer = DXENDLY(1) | XDMAEN | XDISABLE; 
// 设 置 receive 的 full. cycle 表示 在 fs 和 data 在 belk 的 相同 边沿 采样 
//RDMAEN - Receive DMA Enable bit 主要 是 DMA req 信号 的 使 能 
//RDISABLE - disable receive 
regs —> reer = RFULL_CYCLE | RDMAEN | RDISABLE; 





/人 /根据 要 设置 的 format ETT AE BU] fs Jer] data 延 时 设置 
// 以 及 信号 极 性 belk FPEF fs 极 性 设置 
//Normal BCLK + FS; FS active low. TX data driven on falling edge of bit clock 
//and RX data sampled on rising edge of bit clock. 
// 对 于 音频 format 的 详细 信息 见 trm21. 2. 4 
switch( fmt & SND SOC. DAIFMT FORMAT MASK) | 
case SND SOC. DAIFMT DS. 
/ * l — bit data delay * / 



































SII 


regs —> rer2 |=RDATDLY(1) ; 
regs —> xcr2 |=XDATDLY(1) ; 
break ; 

case SND SOC. DAIFMT LEFT J: 
/ * 0 — bit data delay * / 








regs -> rcr2 |= RDATDLY(0) ; 

regs 一 > xcr2 |=XDATDLY(0) ; 

regs —>sperl — | RJUST(2) ; 

/ * Invert FS polarity configuration * / 
//fs 信号 极 性 反 

temp. fmt ^ =SND_SOC_DAIFMT_NB_IF; 
break ; 


case SND_SOC_DAIFMT_DSP_A: 
/ * l — bit data delay * / 
regs — > rer2 |=RDATDLY(1) ; 
regs 一 > xcr2 |=XDATDLY(1) ; 





/ * Invert FS polarity configuration * / 
//fs 信号 极 性 反 
temp. fmt ^= SND. SOC DAIFMT NB IF; 
break; 
case SND SOC DAIFMT DSP B: 
/ * 0 — bit data delay * / 
regs -> rcr2 |= RDATDLY(0) ; 
regs 一 > xcr2 |=XDATDLY(0) ; 








/ * Invert FS polarity configuration * / 
//fs 信号 极 性 反 
temp. fmt ^= SND. SOC DAIFMT NB IF; 
break ; 

default ; 
/ * Unsupported data format * / 
return — EINVAL; 











// 做 master/slave 的 设置 
switch( fmt & SND SOC. DAIFMT MASTER. MASK) | 
case SND SOC. DAIFMT CBS CFS: 
/ ** McBSP master. Set FS and bit clocks as outputs * / 
// llt master , fs 和 clk 信号 输出 
regs —» pcr0 |=FSXM | FSRM | 
CLKXM | CLKRM; 























/ * Sample rate generator drives the FS * / 
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/产生 采样 信号 
regs — > srgr2 | = FSGM; 
break ; 
case SND_SOC_DAIFMT_CBM_CFM; 
/ * McBSP slave * / 
break ; 
default; 
/ * Unsupported master/slave configuration * / 
return — EINVAL; 





/ * Set bit clock( CLKX/CLKR ) and FS polarities * / 
// BCE. belk 信号 和 fs 信号 极 性 
switch( temp. fmt & SND_SOC_DAIFMT_INV_MASK) | 
case SND. SOC. DAIFMT NB NF: 
J * 
* Normal BCLK + FS. 
* FS active low. TX data driven on falling edge of bit clock 








* and RX data sampled on rising edge of bit clock. 
*/ 
// SET E fs FI clk 极 性 设置 都 设 为 nb + nf 
regs —> pcr0 |=FSXP | FSRP | 
CLKXP | CLKRP; 





break ; 

case SND_SOC_DAIFMT_NB_IF: 
//clk 极 性 设置 设 为 nb 
regs —» pci |=CLKXP | CLKRP; 
break ; 

case SND. SOC, DAIFMT IB. NF: 
//fs 极 性 设置 设 为 of 
regs —» pcr |=FSXP | FSRP; 
break ; 

case SND. SOC, DAIFMT IB IF: 
//ABAILA ib + if 
break ; 

default ; 
return — EINVAL; 
































return 0; 
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由 以 上 代码 分 析 可 见 ， 主 要 是 设计 寄存 器 的 操作 ， 在 注释 中 已 经 对 实际 的 操作 进行 了 说 
明 ， 具 体 的 寄存 器 信息 在 芯片 手册 中 有 更 详尽 的 描述 。 

4. codec 模块 

对 codec 模块 部 分 ， 之 前 在 codec 的 注册 函数 snd_soc_register_codec 定义 可 见 其 会 将 co- 
dec driver 和 codec (AY dai 同时 注册 ， 因 为 这 两 者 都 是 与 codec 相关 的 。 这 里 以 DM3730 板 
上 的 twl4030 为 例 ， 介 绍 相关 的 框架 。 首 先是 dai 接口 说 明 。 


static struct snd_soc_dai_driver twl4030. dai[ ] = | 
| 
. name = " twl4030 — hifi" , 
. playback = | 
. stream. name = " HiFi Playback" , 
. channels, min 22, 
. channels max =4, 
. rates = TWLA4030. RATES | SNDRV. PCM, RATE 96000, 
. formats = TWLA030. FORMATS, | , 
. capture = | 
. Stream, name =" Capture" , 
. channels, min 22, 
. channels, max 24, 
. rates = TWLA030. RATES, 
. formats = TWL4030. FORMATS, | , 
. ops = &twl4030 dai hifi ops, 
P 
E 


可 见 同 处 理 需 侧 的 dai 相同 ， 都 是 进行 接口 能 力 的 说 明和 操作 接口 的 说 明 。 操 作 接口 与 处 
理 器 侧 的 dai 功能 上 是 一 致 的 ， 只 是 实际 的 操作 要 通过 处 理 器 的 工 C 总 线 操作 来 完成 。 
codec 驱动 的 细节 如 下 : 


static struct snd_soc_codec_driver soc_codec_dev_twl4030 = | 
. probe = twl4030_soc_probe, 
. remove = twl4030. soc, remove, 
. suspend = twl4030. soc, suspend , 
. resume = twl4030. soc, resume, 
. read = twl4030, read. reg. cache, 
. write = twl4030, write, 
. set. bias, level = twl4030. set, bias level, 
.reg cache size = sizeof( twl4030. reg) , 
. reg word, size = sizeof( u8 ) , 


. reg cache default = tw14030. reg, 
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这 里 主要 是 对 codec 管理 的 接口 ， 下 面 来 看 一 下 probe 的 实现 细节 : 


static int twl4030_soc_probe( struct snd_soc_codec * codec ) 


| 
struct twl4030_priv * twl4030; 


twl4030 = kzalloc ( sizeof( struct twl4030_priv) ,GFP_KERNEL) ; 
if( twl4030 == NULL) | 
printk ( " Can not allocate memroy Wn" ) ; 
return - ENOMEM ; 
} 
// 设 置 设备 特殊 属性 


snd_soc_codec_set_drvdata( codec , twl4030 ) ; 











/ * Set the defaults ,and power up the codec * / 
twl4030 -> sysclk = twl4030. codec. get. melk( )/ 1000; 


codec —> idle, bias offz1; 


twl4030. init, chip( codec) ; 


// 增 加 音频 控制 接口 

snd. soc, add. controls ( codec ,twl4030_snd_controls, 
ARRAY. SIZE( twl4030. snd, controls) ) ; 

// 增 加 DAPM 接口 

twl4030_add_widgets( codec) ; 


return 0; 


| 











可 见 主要 是 对 设备 特殊 的 属性 进行 设置 ， 另 外 就 是 增加 控制 接口 ， 这 样 系统 就 可 以 通过 
这 些 控制 接口 直接 操作 codec。 对 于 codec 主要 是 由 codec driver 来 提供 控制 接口 ， 而 由 codec 
dai 来 提供 数据 传输 能 力 。 

这 样 对 DM3730 ALSA SoC 中 各 个 模块 的 实现 都 进行 了 分 析 和 说 明 。 


6.3.5 音频 驱动 电源 管理 相关 说 明 


对 于 音频 驱动 的 电源 管理 部 分 ，ALSA SoC 框架 层 提供 了 基本 的 电源 管理 框架 ， 之 前 在 
其 与 底层 platform 关联 的 platform driver 中 可 见 有 电源 管理 的 操作 接口 soc_pm_ops。 详 细 内 容 
如 下 : 

















static const struct dev_pm_ops soc_pm_ops = | 
. suspend = soc, suspend , 
. resume = soc, resume, 
. poweroff = soc. poweroff , 


F 
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主要 的 电源 管理 操作 就 是 通过 这 些 接口 实现 的 。 下 面 分 析 soc_suspend 的 细节 : 





static int soc. suspend( struct device * dev) 

| 
struct platform, device * pdev = to_platform_device( dev) ; 
struct snd_soc_card * card = platform_get_drvdata( pdev) ; 


int 1; 


/ * If the initialization of this soc device failed, there is no codec 
* associated with it. Just bail out in this case. 
*/ 

if(list empty ( &card -> codec. dev. list) ) 


return 0; 


// 保 证 card 处 于 power on 状态 才能 执行 suspend 操作 
snd. power. lock( card -> snd, card) ; 
snd. power. wait( card -> snd card, SNDRV, CTL POWER, DO) ; 


snd. power, unlock ( card -> snd, card) ; 


// 应 用 层 的 操作 都 需要 card 处 于 SNDRV. CTL. POWER. DO ,这 里 设置 
// 不 同 的 power 状态 保证 屏蔽 应 用 层 的 操作 
snd_power_change_state( card -> snd_card ,SNDRV_CTL_POWER_D3hot) ; 








/ * mute any active DAC s * / 
// 对 所 有 stream 中 的 codec dai 进行 mute 操作 
for(i =0;i «card -> num rtd;i ++ ) | 
struct snd, soc, dai * dai = card —» rtd[ i]. codec, dai; 


struct snd, soc, dai, driver * drv = dai —> driver; 


if( card —» rtd[ i]. dai. link —» ignore, suspend ) 


continue ; 


if( drv -> ops —» digital. mute && dai -> playback, active) 
drv —> ops —> digital, mute( dai,1) ; 


/ * suspend all pems * / 
// 对 所 有 的 pem 进行 stream 操作 
for(i=0;i<card -> num rtd;i ++ ) | 
if( card —> rtd[ i]. dai_link —> ignore, suspend ) 
continue ; 


// ALSA 框架 提供 了 pem 的 操作 接口 ,其 中 会 触发 具体 设备 的 trigger 
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/进行 相应 的 suspend 操作 


snd_pcm_suspend_all(card —» rtd[ i]. pem) ; 


if( card -> suspend, pre) 


card -> suspend, pre( pdev, PMSG. SUSPEND) ; 


// 对 处 型 


for(i =0;i < card -> num rtd;i ++ ) | 














器 侧 的 dai 和 platform 进行 suspend 操作 ,通常 相应 的 操作 为 空 











struct snd_soc_dai * cpu, dai = card —> rtd[ i]. cpu, dai; 


struct snd, soc, platform * platform = card —> rtd[ i]. platform; 


if( card —» rtd[ i]. dai. link —> ignore, suspend ) 


continue ; 


if( cpu, dai -> driver — > suspend && ! cpu, dai -> driver -> ac97. control) 
cpu, dai -> driver — > suspend( cpu, dai) ; 

if( platform -> driver -> suspend && ! platform -> suspended) | 
platform -> driver — > suspend( cpu. dai ) ; 
platform -> suspended = 1 ; 


/ * close any waiting streams and save state * / 
// 这 里 进行 后 续 的 操作 ,主要 是 通过 work 必要 时 发 送 DAPM 的 stop 事件 


事件 
for(i=0;i<card->num rtd;i ++ ) | 


























run, delayed. work ( &card —» rtd[ i]. delayed work) ; 


card —» rtd[ i]. codec -> suspend. bias level = card -> rtd[ i]. codec —» bias, level; 


// 对 各 个 stream KIL DAPM 的 suspend 


for(i=0;i<card->num rtd;i ++ ) | 


ln] 








EF 


struct snd, soc, dai, driver * driver = card —» rtd[ i]. codec. dai -> driver; 


if( card —» rtd[ i]. dai, link —> ignore, suspend ) 


continue ; 


if( driver -> playback. stream. name != NULL) 


snd. soc, dapm, stream. event( &card —» rtd[ i] , driver -> playback. stream, name, 
SND. SOC. DAPM, STREAM, SUSPEND) ; 





if( driver -> capture. stream, name != NULL) 
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snd_soc_dapm_stream_event( &card —> rtd[ i ] , driver -> capture. stream, name, 


SND_SOC_DAPM_STREAM_SUSPEND) ; 





/ * suspend all CODECSs * / 
T 
for(i =0;i «card -> num rtd;i ++ ) | 
struct snd, soc, codec * codec = card -> rtd[ i]. codec; 
/ * If there are paths active then the CODEC will be held with 
* bias _ON and should not be suspended. * / 
if( ! codec —» suspended && codec —> driver —» suspend) | 
// 根 据 codec 的 偏 置 电压 等 级 进行 相应 的 设置 
switch( codec — > bias. level) | 
case SND. SOC. BIAS. STANDBY: 
case SND SOC. BIAS. OFF: 
codec -> driver -> suspend( codec , PMSG, SUSPEND) ; 
codec -> suspended =1; 
break ; 
default : 
dev. dbg( codec -> dev," CODEC is on over suspend n" ) ; 
break ; 











for(i =0;i «card -> num rtd;i ++ ) | 


struct snd_soc_dai * cpu, dai = card —> rtd[ i]. cpu, dai; 


if( card —» rtd[ i]. dai. link —> ignore, suspend ) 


continue ; 


// Ff ac97 才 进 行 该 操作 
if( epu, dai -> driver — > suspend && cpu, dai -> driver -> ac97_control ) 


cpu, dai -> driver — > suspend ( cpu, dai) ; 


//soc card 后 续 的 操作 
if( card —> suspend_post) 
card —» suspend, post( pdev, PMSG_SUSPEND) ; 


return 0; 
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从 分 析 中 可 见 ，ALSA 框架 提供 的 电源 管理 能 力主 要 由 snd_pcm_suspend_all 实现 ， 另 外 
在 ALSA SoC 框架 中 由 各 个 模块 实现 相应 操作 ， 还 有 部 分 功能 由 DAPM 实现 。 

DAPM 是 dynamic audio power management (动态 音频 电源 管理 ) 的 缩写 。DAPM 的 目的 
是 降低 音频 设备 的 功 耗 。DAPM 对 应 用 程序 来 说 是 透明 的 ， 所 有 与 电源 相关 的 开关 都 在 
ALSA SoC 架构 中 完成 ，DAPM 根据 当前 激活 的 音频 流 (playback 或 capture) 和 card 中 的 
mixer 等 的 配置 来 决定 音频 控件 模块 的 打开 或 关闭 。 

由 于 音频 设备 中 会 有 不 同 的 功能 节点 ， 通 过 这 些 节点 的 设置 会 有 完全 不 同 的 音频 通道 ， 
DAPM 本 身 则 需要 能 够 维护 这 些 不 同 节点 的 功能 ， 以 及 相应 产生 的 音频 通道 ， 在 相关 的 电源 
管理 操作 时 则 会 根据 音频 通道 中 各 个 音频 节点 进行 对 应 的 操作 ， 系 统 提供 的 相应 接口 是 
dapm_power_widgets， 对 应 具体 的 音频 节点 则 是 由 snd_soc_dapm_widget 结构 进行 管理 。 

总 体 来 说 DAPM 主要 是 对 整个 音频 流 (主要 是 audio codec 内 部 的 ) 中 的 各 个 节点 以 及 
路 径 进行 管理 ， 这 样 保证 在 运行 过 程 中 可 以 根据 整个 音频 流 的 不 同 状 态 进 行 合理 地 控制 ， 以 
减少 功 耗 和 保证 良好 的 音频 效果 。 运 行 时 管理 的 重点 是 在 节点 和 路 径 上 。 

先 来 看 看 DAPM 定义 的 节点 管理 实体 snd_soc_dapm_widget， 分 析 如 下 : 






























































struct snd_soc_dapm_widget | 
// 类 型 
enum snd_soc_dapm type id; 
char * name; / * widget name * / 
char * sname; / * stream name * / 
// 所 属 的 audio codec 
struct snd_soc_codec * codec; 
//widget 的 链表 


struct list_head list; 





/ * dapm control * / 

// 控 制 寄存 能 

short reg; / * negative reg = no direct dapm * / 
// 控 制 偏 移 位 

unsigned char shift; / * bits to shift * / 

// 保 存 的 值 

unsigned int saved_value; / * widget saved value * / 

// 当 前 状态 的 值 

unsigned int value; / * widget current value * / 

// 控 制 屏蔽 值 ,保证 只 对 该 widget 进行 控制 
unsigned int mask; / * non — shifted mask * / 
// 当 电源 开启 的 值 

unsigned int on_val; / * on state value * / 

// 当 电源 关闭 的 值 


unsigned int off_val; / * off state value * / 
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// 以 下 是 运行 时 的 状态 信息 
//power 的 状态 









































unsigned char power:1; / * block power status * / 

// power 位 是 否 需 要 逻辑 翻转 

unsigned char invert:1; / * invert the power bit * / 

// 表 示 widget 是 否 激活 

unsigned char active;1; / * active stream on DAC, ADC s * / 
// 表 示 widget 是 否 在 音频 通路 上 

unsigned char connected ; 1; / * connected codec pin * / 

/人 /初始 化 的 状态 , 置 位 表示 已 经 实例 化 

unsigned char new:1; / * cnew complete * / 

// RINK widget 是 否 有 外 部 信号 连接 

unsigned char ext:1; / * has external widgets * / 
// 强 制 状 态 ,用 于 进行 电源 管理 时 不 对 当前 状态 进行 检查 ,直接 操作 
unsigned char force:1; / * force state * / 

unsigned char ignore_suspend; | ; / * kept enabled over suspend * / 


// 检 查 当前 power 状态 的 接口 ,不 同类 型 的 widget 对 于 power 的 状态 检查 的 依据 
// 是 不 同 的 ,DAPM 为 不 同类 型 的 widget 提供 了 不 同 的 接口 函数 . 


int( * power check) ( struct snd_soc_dapm_widget * w) ; 


/ * external events * / 
/人 /表示 该 widget 关注 的 DAPM 事件 类 型 

unsigned short event_flags ; / * flags to specify event types * / 
// 处 理 DAPM 事件 的 接口 


int( * event) (struct snd_soc_dapm_widget * ,struct snd_kcontrol * , int) ; 














/ * kcontrols that relate to this widget * / 
// Fj widget 相关 功能 控制 相关 的 控制 元 素 信 息 


int num_kcontrols; 





const struct snd_kcontrol_new * kcontrols ; 


/ * widget input and outputs * / 
// 所 有 从 source 到 该 widget 的 path 链接 
struct list head sources; 


// 所 有 从 该 widget 去 往 sink 的 path 链接 


struct list_head sinks; 


/ * used during DAPM updates * / 
// 如 果 该 widget 需要 进行 一 定 的 DAPM 操作 , 则 会 加 入 到 对 应 的 链表 中 


struct list head power. list ; 
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DAPM 提供 了 一 批 宏 





义 ， 用 于 相应 的 codec 驱动 对 widget 进行 定义 。 了 驱动 会 根据 特定 


定 
widget 的 特点 (如 是 否 能 进行 DAPM 事件 处 理 ， 是 否 有 控制 能 力 ) 选择 宏 进行 定义 。 
另外 一 个 重要 的 执行 管理 实体 是 path, H snd_soc_dapm_path 进行 管理 ， 细 节 如 下 : 


以 使 音 











struct snd_soc_dapm_path | 


ls 


char ** name; 


char * long name; 


//path 中 数据 源 widget 

struct snd_soc_dapm_widget * source; 
//path 中 数据 目的 widget 

struct snd_soc_dapm_widget * sink; 
//path 中 的 控制 元 素 


struct snd, kcontrol * kcontrol ; 





// path 在 当前 音频 流 中 的 状态 

u32 connect :1 ; / * source and sink widgets are connected * / 
// 在 进行 DAPM 操作 时 是 否 已 经 遍历 过 该 path ,避免 重复 遍历 
u32 walked:1;/ * path has been walked * / 








// 连 接 时 的 操作 接口 , 某 些 codec 需要 ,一般 为 空 
int( * connected) ( struct snd_soc_dapm_widget * source， 


struct snd, soc. dapm. widget * sink) ; 


// 有 相同 source widget 的 path 的 链表 
struct list head list, source; 
// 有 相同 sink widget 的 path 的 链表 
struct list head list, sink ; 

//%E* codec 的 所 有 path 的 链表 


struct list_head list; 








可 见 path 是 连接 两 个 widget 节点 的 实体 ， 其 中 的 kcontrol 是 根据 相关 的 widget 进行 创建 
的 ， 而 必要 的 情况 如 mixer 和 mux 会 将 kcontrol 添加 到 应 用 层 。 通 过 应 用 层 对 kcontrol 操作 可 
频 路 径 发 生变 化 。snd_soc_dapm_path 管理 动态 的 path 信息 ， 而 设备 中 静态 的 连接 信 
息 由 snd_soc_dapm_route 定义 ， 并 和 widget 一 起 在 初始 化 时 产生 snd_soc_dapm_path 信息 以 
及 对 应 用 的 kcontrol 控制 元 素 。 

整个 音频 路 径 中 有 效 的 音频 路 径 概括 为 从 DAC 至 output pin, M input pin 至 ADC, M 
input pin 至 output pin、 从 DAC 至 ADC 等 这 几 类 。 耸 何 时 当 任 何 音 频 路 径 
中 有 状态 发 生变 化 时 ， 部 需要 过 和 了 全 局 的 路 径 有 效 性 检查 ， 将 整个 音频 路 径 的 相关 节点 及 配 
ed 了 正确 的 操作 ， 这 个 工作 在 DAPM 中 最 终 是 由 dapm_power_ dels 来 实现 的 ， 下 面 对 


行 分 析 。 
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static int dapm_power_widgets( struct snd_soc_codec * codec, int event) 
| 

struct snd_soc_card * card = codec —> card; 

struct snd_soc_dapm_widget * w; 

LIST. HEAD( up list) ; 

LIST. HEAD( down, list) ; 

int ret 20; 

int power; 


int sys. power 20; 


//3hàJ] codec 所 有 的 widget 
list. for each, entry( w, &codec -> dapm. widgets , list) | 
switch( w —» id) | 
// 如 果 定 义 为 DAPM ,特殊 操作 的 widget 则 加 入 到 合适 的 操作 队列 
case snd_soc_dapm_pre: 
dapm, seq. insert( w , &down_list ,dapm_down_seq) ; 
break ; 
case snd, soc, dapm. post: 
dapm, seq. insert( w, &up. list, dapm up. seq) ; 
break ; 


default : 
// 没 有 power check 接口 ,说 明 没 有 实例 化 
if( lw —» power, check) 


continue ; 


// 检 查 需 要 的 power 状态 
if( ! w —» force) 


power = w —» power. check( w) ; 


else 

power =1; 
// 8 widget 需要 power, JPA codec 系统 就 需要 power 
if( power) 


Sys power =1; 


if( w -> power == power) 


continue ; 


// widget 当前 的 power 状态 与 希望 的 不 同 需要 将 其 加 入 对 应 的 队列 
// 需 要 关闭 加 入 down 队列 ,需要 打开 加 入 up 队列 
if( power) 


dapm_seq_insert(w, &up_list ,dapm_up_seq) ; 
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else 


dapm_seg_insert(w, &down_list ,dapm_down_seq) ; 


// 这 里 设置 新 的 power 状态 
w —> power = power; 


break ; 





























// 那 些 没 有 通过 widget 进行 电源 控制 的 codec ,由 系统 整体 的 电源 控制 
if( list_empty( &codec -> dapm_widgets) ) | 

















switch( event) | 
case SND. SOC. DAPM, STREAM. START: 
case SND_ SOC. DAPM, STREAM. RESUME: 


sys power = 1; 











break ; 

case SND SOC DAPM STREAM. STOP: 
sys. power = | ! codec -> active; 
break ; 


case SND. SOC. DAPM, STREAM, SUSPEND: 





sys power 20; 
break ; 
case SND. SOC. DAPM, STREAM, NOP: 





switch (codec — > bias. level) | 
case SND_SOC_BIAS_STANDBY: 
case SND_SOC_BIAS_OFF: 


sys_power =0; 


break ; 
default : 

sys_power =1; 
break ; 

} 

break ; 

default : 
break ; 





























// 根 据 当前 需要 codec 系统 电源 情况 及 偏 置 电 压 状 态 进行 正确 的 设置 
if( sys. power && codec -> bias, level ==SND_SOC_BIAS_OFF) | 
ret = snd, soc, dapm, set. bias level( card , codec, SND. SOC. BIAS STANDBY) ; 
if( ret 120) 
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pr. err( " Failed to turn on bias; 96 d\n" ,ret) ; 


/ ** If wé re changing to all on or all off then prepare * / 
if( (sys power && codec —> bias. level == SND, SOC. BIAS. STANDBY ) || 
( ! sys. power && codec -> bias level == SND. SOC, BIAS. ON) ) | 
ret = snd, soc, dapm, set. bias level( card , codec, SND. SOC. BIAS PREPARE) ; 
if( ret 120) 
pr. err( " Failed to prepare bias; 96 d\n" , ret) ; 





/ ** Power down widgets first ;try to avoid amplifying pops. * / 
// 为 了 避免 pop 音 先 关 掉 需 要 关 掉 的 部 分 


dapm_seq_run( codec , &down_list , event, dapm, down. seq) ; 








/ * Now power up. */ 
/打开 需要 打开 的 部 分 


dapm_seq_run( codec, &up. list, event ,dapm_up_seq) ; 


/ * If we just powered the last thing off drop to standby bias * / 
// 后 续 的 系统 操作 ,保证 偏 置 电压 的 正确 操作 过 程 
if( codec —> bias level ==SND_SOC_BIAS_PREPARE && | sys_power) | 
ret = snd, soc, dapm, set. bias level( card , codec, SND. SOC. BIAS STANDBY) ; 
if( ret 120) 
pr. err( " Failed to apply standby bias; % d\n" ,ret) ; 


























/ * If wé re in standby and can support bias off then do that * / 
if( codec -> bias, level == SND. SOC. BIAS STANDBY && 
codec —> idle, bias. off) | 
ret = snd, soc, dapm, set. bias level( card , codec, SND. SOC. BIAS. OFF) ; 
if(ret ! 20) 
pr. err( " Failed to turn off bias; 96 d\n" ,ret) ; 





/ * If we just powered up then move to active bias * / 

if( codec — > bias level == SND. SOC, BIAS PREPARE && sys, power) | 
ret = snd, soc, dapm, set. bias level( card , codec, SND. SOC. BIAS. ON) ; 
if( ret 120) 





pr. err( " Failed to apply active bias; % d\n" , ret) ; 


pop. dbg( codec -> pop. time, " DAPM sequencing finished, waiting % dms\n" , 
codec —> pop. time) ; 


pop. wait( codec -> pop. time) ; 


return 0; 


| 


从 分 析 中 可 见 ， 该 过 程 会 把 握 整 个 变化 ， 进 行 正确 的 设置 ， 从 而 保证 系统 根据 状态 进行 
正确 的 切换 ， 在 保证 功能 的 情况 下 ， 达 到 功 耗 尽量 低 ， 从 而 完成 整个 动态 调整 的 功能 。 在 实 
现 过 程 中 通过 将 与 音频 路 径 相 关 的 kcontrol 控制 元 素 包 含 进 DAPM 管理 实体 ， 就 可 以 监控 系 
统 设 置 以 及 应 用 设置 导致 的 状态 变化 ， 从 而 进行 正确 的 操作 。 这 样 就 完整 实现 了 整个 音频 的 
电源 管理 功能 。 











6.4 视频 驱动 (V4L2 ) 


6.4.1 视频 驱动 需求 


在 各 种 各 样 的 应 用 设备 中 ,发展 最 快 、 变 化 最 多 的 就 是 视频 设备 。 之 前 在 介绍 帧 组 
冲 驱 动 时 提 到 的 显示 设备 分 辨 率 长 宽 比 有 不 同 的 标准 ， 其 中 电视 标准 设备 的 输出 以 及 vid- 
eo 视频 通道 的 输出 就 与 视频 设备 相关 。 但 是 视频 设备 远 不 止 于 此 ， 视 频 设备 的 发 展 是 与 
视觉 技术 和 电视 技术 发 展 息息相关 的 ， 其 中 涉及 视频 采集 、 视 频 编码 /解码 、 视 频传 输 、 
视频 显示 等 各 个 方面 ， 可 以 说 已 经 形成 了 一 个 完整 的 链条 。 其 在 人 们 的 现实 生活 中 也 越 
KREZ, 

现 如 今 视 频 设备 已 经 不 完全 局 限于 视频 功能 ， 由 于 视频 设备 与 多 媒体 的 关系 很 紧密 ， 有 
些 设备 还 需要 有 音频 的 功能 ， 这 样 视频 设备 更 像 是 一 个 容器 ,包含 各 种 功能 。 大 部 分 现代 
视频 设备 由 多 个 处 理 器 组 成 ， 在 物理 上 还 需要 一 定 的 连接 总 线 来 进行 控制 ， 这 就 进一步 增加 
了 系统 的 复杂 程度 。 

面 对 如 此 复杂 的 设备 ， 对 视频 驱动 来 说 是 个 不 小 的 挑战 ， 对 驱动 框架 同样 有 很 高 的 要 
求 。 视 频 驱 动 需要 能 够 控制 这 些 不 同 的 设备 ， 应 用 层 也 要 求 能 够 通过 简单 的 控制 接口 访问 到 
设备 的 信息 ， 并 进行 控制 ， 另外 还 需要 能 够 方便 地 进行 设备 特殊 的 控制 ; 应 用 还 需要 能 够 了 
解 设备 内 部 的 各 个 模块 的 拓扑 情况 ， 并 能 对 不 同 的 数据 通道 进行 灵活 的 配置 。 

以 上 的 需求 在 设备 管理 方面 与 音频 设备 有 一 些 相 同 ， 但 是 由 于 视频 设备 的 复杂 度 要 更 
高 ， 所 以 相应 的 驱动 也 更 复杂 。 

6.4.2 视频 驱动 框架 解析 

为 了 满足 以 上 的 需求 ， 视 频 驱 动 框架 分 别 在 不 同 的 层次 进行 了 设计 ， 以 实现 不 同 层面 的 
巨大 挑战 。 

1. 应 用 层 设备 访问 以 及 控制 

要 了 解 应 用 层 如 何 访问 设备 还 是 先 从 顶层 的 文件 操作 开始 ， 视 频 框架 提供 的 顶层 文件 操 
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作 接 口 是 v412_fops， 详 细 内 容 如 下 : 


static const struct file operations v412_fops = | 
. owner = THIS MODULE, 
. read = v4D2. read, 
. write = v4I2. write, 
. open = v4. open, 
. mmap = v42. mmap, 


. unlocked_ioctl = v412_ ioctl, 


. release = v412_release, 
. poll = v412_poll, 
. llseek = no Ilseek , 


l; 








可 见 与 其 他 类 型 的 功能 设备 并 没有 太 大 的 差别 ， 继 续 从 open 接口 了 解 框架 是 如 何 管理 
其 设备 的 。 





static int v4l2_open( struct inode * inode, struct file * filp) 
| 
struct video_device * vdev; 
#if defined( CONFIG_MEDIA_CONTROLLER ) 
struct media_entity * entity = NULL; 
#endif 


int ret =0; 


/ * Check if the video device is available * / 
mutex, lock ( &videodev, lock) ; 
// 找 到 正确 的 管理 实体 
vdev = video, devdata( filp) ; 
/ * return ENODEV if the video device has already been removed. * / 
if( vdev == NULL || ! video. is, registered( vdev) ) | 
mutex, unlock ( &videodev, lock) ; 
return - ENODEV ; 
} 
/ * and increase the device refcount * / 
video_get(vdev) ; 
mutex, unlock ( &videodev_lock ) ; 
#if defined( CONFIG_MEDIA_CONTROLLER ) 
if( vdev -> v412_dev && vdev -> v4I2, dev -> mdev) | 
entity = media, entity. get( &vdev —» entity) ; 
if( ! entity) | 
ret = — EBUSY; 
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video, put( vdev) ; 


return ret; 


} 
#endif 
if( vdev -> fops -> open) | 
if( vdev -> lock && mutex, lock, interruptible( vdev -> lock ) ) | 
ret = — ERESTARTSYS; 
goto err; 
} 
人/ 进行 实际 设备 的 open 操作 
if( video_is_registered( vdev) ) 
ret = vdev 一 > fops -> open( filp) ; 
else 
ret = — ENODEV; 
if( vdev -> lock) 


mutex, unlock ( vdev —> lock) ; 


em; 
/ * decrease the refcount in case of an error * / 
if( ret) | 
#if defined( CONFIG. MEDIA, CONTROLLER ) 
if( vdev -> v4l2_dev && vdev -> v412_dev -> mdev) 
media, entity. put( entity) ; 
#endif 
video, put( vdev) ; 


| 


return ret; 


| 


首先 代码 中 出 现 了 CONFIG_MEDIA_CONTROLLER 宏 ， 这 是 可 配置 单元 ， 与 设备 内 拓扑 
及 连接 管理 相关 ， 后 续 会 进行 详细 介绍 。 从 代码 分 析 中 可 见 ， 郴 数 主要 是 通过 video_devdata 
来 获得 一 个 video_device 结构 体 的 指针 ， 紧 接着 就 调用 其 中 的 open 函数 ， 这 个 video_device 
就 是 针对 应 用 层 的 管理 实体 ， 相 应 的 所 有 应 用 层 的 调用 都 会 通过 其 中 转 到 实际 设备 的 操作 
中 。 这 个 管理 实体 如 此 重要 ， 相 应 的 系统 就 应 该 提供 其 注册 函数 ， 其 中 底层 的 注册 接口 是 
_video_register_device ， 详 细 分 析 如 下 : 
































int __video_register_device( struct video, device * vdev, int type, int nr, 


int warn, if nr in, use,struct module * owner) 


int 1 20; 
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int ret; 

int minor_offset =0; 

int minor cnt = VIDEO. NUM, DEVICES; 
const char * name, base; 


void * priv = vdev —> dev. p; 


/ * A minor value of — 1 marks this video device as never 
having been registered * / 


vdev -> minor = -1; 


/ * the release callback MUST be present * / 
WARN. ON( ! vdev —> release) ; 
if( | vdev -> release) 


return — EINVAL; 


/ * v4]2. fh support * / 
spin, lock init( &vdev —» fh. lock) ; 
INIT. LIST HEAD( &vdev —> fh. list) ; 


/ * Part 1; check device type * / 

// 根 据 设备 类 型 产生 基础 的 设备 名 字 
switch( type) | 

case VFL TYPE CGRABBER: 














name, base = " video" ; 
break ; 
case VFL TYPE VBI: 
name, base = " vbi" ; 
break ; 
case VFL_TYPE_RADIO: 
name_base = "radio" ; 
break ; 
case VFL_TYPE_SUBDEV: 
name, base = " v4] — subdev" ; 
break ; 
default : 
printk( KERN, ERR " 96s called with unknown type; 96 dn" , 
__func__, type) ; 
return — EINVAL; 


vdev —> vfl_type = type; 
vdev —>cdev = NULL; 
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// 这 里 与 设备 层次 相关 
if( vdev -> v412_dev) | 
if( vdev —>v4l2_dev -> dev) 
vdev -> parent = vdev -> v412. dev -> dev; 
// 这 里 和 特殊 的 控制 相关 ,关联 v412_dev 中 的 控制 元 素 
if( vdev -> ctrl_handler == NULL) 


vdev -> ctrl_handler = vdev -> v412_dev —> ctrl_handler; 








/ * Part 2; find a free minor,device node number and device index. * / 


/ * Pick a device node number * / 
mutex_lock ( &videodev_lock ) ; 
nr = devnode, find( vdev,nr == -1 ? 0 ; nr,minor_ent) ; 
if( nr == minor ent) 
nr = devnode, find( vdev ,0 , minor. ent) ; 
if( nr == minor ent) | 
printk( KERN, ERR "could not get a free device node number Wn" ) ; 
mutex, unlock ( &videodev, lock) ; 
return — ENFILE ; 


























// 这 里 根据 之 前 找到 的 子 设备 号 设置 ,注意 子 设备 号 与 设备 索引 不 同 


vdev —» minor = i + minor_offset; 




















vdev -> num = nr; 


devnode. set( vdev ) ; 


/ * Should not happen since we thought this minor was free * / 
WARN. ON( video_device| vdev -> minor] !=NULL) ; 
vdev —> index = get, index( vdev) ; 


mutex, unlock ( &videodev, lock) ; 


/ * Part 3: Initialize the character device * / 
/注册 字符 设备 
vdev —» edev = cdev_alloc() ; 
if( vdev -> cdev == NULL) | 
ret = — ENOMEM; 
goto cleanup; 
} 
vdev -> cdev -> ops = &v412_fops; 
vdev —» cdev —> owner = owner; 


// 可 见 每 个 子 设备 号 都 会 创建 字符 设备 
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ret = cdev_add( vdev -> edev, MKDEV( VIDEO_MAJOR, vdev -> minor) ,1) ; 
if( ret <0) | 

printk( KERN. ERR "%s; cdev_add failed\n" ,__func__) ; 

kfree( vdev -> cdev) ; 

vdev -> cdev = NULL; 


goto cleanup; 


/ ** Part 4; register the device with sysfs * / 
// 这 里 创建 sysfs 设备 模型 相关 信息 ,与 设备 文件 相关 


memset( &vdev -> dev,0,sizeof(vdev -> dev) ) ; 























/ * The memset above cleared the devicé s device private ,so 
put back the copy we made earlier. * / 

vdev —> dev. p = priv; 

vdev —> dev. class = &video, class; 

// 设 备 号 

vdev -> dev. devt = MKDEV ( VIDEO. MAJOR ,vdev -> minor) ; 

if( vdev -> parent ) 
vdev —> dev. parent = vdev —> parent; 

// 设 备 名 与 设备 类 型 和 索引 号 相关 


dev_set_name( &vdev -> dev ," % s% d" ,name_base,vdev -> num) ; 





ret = device_register( &vdev -> dev) ; 
if( ret <0) | 
printk( KERN, ERR "%s; device register failed\n" ,__func__) ; 
goto cleanup; 
} 
/ * Register the release callback that will be called when the last 
reference to the device goes away. * / 


vdev —> dev. release = v412_device_release ; 


if(nr != -1 && nr !=vdev -> num && warn, if nr in use) 
printk( KERN, WARNING "96s; requested %s%d,got %s\n",__fune_, 
name, base, nr, video, device, node name( vdev) ) ; 
#if defined( CONFIG MEDIA, CONTROLLER ) 
/ * Part 5; Register the entity. * / 
// 此 处 与 设备 连接 管理 相关 
if( vdev -> v412_dev && vdev —> v4I2, dev -> mdev) | 
vdev —> entity. type = MEDIA_ENTITY_TYPE_DEVNODE_V4L; 
vdev -> entity. name = vdev -> name; 
vdev —> entity. v4l. major = VIDEO. MAJOR ; 


vdev —> entity. v4l. minor = vdev —> minor; 





ret = media, device, register entity( vdev -> v412. dev -> mdev, 


530 


&vdev —> entity) ; 
if( ret <0) 
printk( KERN. WARNING 

"%s: media, device register entity failed Wn" , 

. fune ); 
} 

#endif 

/ * Part 6; Activate this minor. The char device can now be used. */ 
// 加 入 系统 进行 管理 
set_bit( VAL2 FL REGISTERED , &vdev -> flags) ; 
mutex, lock ( &videodev_lock ) ; 








video. device[ vdev -> minor | = vdev; 


mutex, unlock ( &videodev_lock ) ; 


return 0; 


cleanup: 
mutex, lock ( &videodev_lock ) ; 
if( vdev -> cdev) 
cdev_del( vdev -> edev) ; 
devnode_clear( vdev) ; 
mutex, unlock ( &videodev, lock) ; 
/ * Mark this video device as never having been registered. * / 
vdev -> minor = -1; 
return ret; 


| 





从 代码 分 析 中 可 见 ， 应 用 层 见 到 的 设备 文件 后 面 的 标号 如 video0 并 不 是 子 设备 号 ， 而 
是 设备 的 索引 号 。 在 注册 中 还 涉及 了 ctrl handler 和 v412_ 人 fh， 都 与 设备 对 用 户 开放 的 功能 相 
关 ， 后 续 会 进行 详细 介绍 。 另 外 其 中 还 包含 了 设备 连接 等 信息 的 初始 化 。 从 中 可 以 一 定 程度 
上 了 解 视 频 驱 动 的 框架 。 不 管 怎 样 ， 对 于 注册 函数 ， 首 先 应 该 明确 video device 的 作用 是 针 
对 应 用 层 接 口 的 管理 实体 。 下 面 先 来 看 看 video device 的 详细 内 容 : 
































struct video_device 

| 

#if defined( CONFIG_MEDIA_CONTROLLER ) 
struct media, entity entity ; 

#endif 
/ * device ops * / 
// 设 备 特殊 的 对 应 用 层 的 操作 接口 


const struct v412_file_operations * fops; 
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/ * sysfs * / 
struct device dev; / * v4] device * / 


struct cdev * cdev; / * character device * / 


/ * Set either parent or v412. dev if your driver uses v4l2, device * / 
// 两 种 模式 会 对 设备 管理 有 不 同 的 影响 ,由 注册 的 代码 可 见 ,这 里 设置 
// 与 控制 相关 


struct device * parent; / * device parent * / 


























struct v4I2. device * v412. dev; / * v4]2. device parent * / 


/ * Control handler associated with this device node. May be NULL. */ 
/控制 相关 


struct v412_ctrl_handler * ctrl_handler; 





/ * device info * / 

char name| 32 | ; 

设备 类 型 

int vfl_type; 

/ * minor is set to — 1 if the registration failed * / 
// 于 设备 号 

int minor; 

RINS 

ul6 num; 

/ * use bitops to set/clear/test flags * / 

// 一 些 状 态 标 记 , 主 要 是 设备 是 否 已 经 注册 


unsigned long flags; 




















/ * attribute to differentiate multiple indices on one physical device * / 


int index; 


/ x VAI2 file handles * / 
// 设 备 事 件 相 关 , 主要 对 应 用 层 处 理 使 用 











spinlock_t fh_lock;/ * Lock for all v412_fhs * / 
struct list. head fh. list;/ * List of struct v412_fh * / 
int debug; / * Activates debug level * / 


/ * Video standard vars * / 
v4I2. std id tvnorms; / * Supported tv norms * / 


vAI2, std. id current, norm; / * Current tvnorm * / 


/ * callbacks ** / 
// 释 放 资 源 接口 ,主要 用 于 释放 device 中 的 设备 私有 管理 实体 





void( * release) ( struct video. device * vdev) ; 


/ * ioctl callbacks * / 
// 设 备 特殊 的 ioctl 接口 


const struct v412_ioctl_ops * ioctl_ops; 


/ * serialization lock * / 
struct mutex * lock; 


is 





从 结构 分 析 中 可 见 ， 其 中 提供 了 两 个 操作 接口 : fops 和 iocl ops, fops 是 针对 应 用 层 的 


操作 接口 ， 其 形式 与 文件 操作 接口 基本 相似 ， 细 广 如 下 : 


struct v412_file_operations | 
struct module * owner; 
ssize_t( * read) (struct file * ,char __user * , size_t, loff_t * ) ; 
ssize_t( * write) (struct file * ,const char __user * ,size t,loff t * ) ; 
unsigned int( * poll) (struct file * ,struct poll table struct * ) ; 
long( * ioctl) (struct file * , unsigned int, unsigned long) ; 
long( * unlocked. ioctl) (struct file * , unsigned int, unsigned long) ; 
int( * mmap) (struct file * , struct vm, area, struct * ) ; 
int( * open) (struct file * ) ; 
int( * release) ( struct file * ) ; 


l; 








ioctl_ops 是 具体 设备 的 ioctl 接口 。 一 般 来 说 iocd 直接 在 应 用 层 操作 接口 提供 即 可 ， 为 





什么 又 定义 一 个 ioctl_ops 来 做 相关 的 工作 呢 ? 这 是 由 于 视频 设备 的 多 样 性 导致 其 I0 控制 太 
多 太 复 杂 ， 视 频 驱 动 框架 提供 了 video_ioctl2 作为 标准 的 处 理 ， 可 以 在 fops 中 将 ioctl 设置 为 
video_ioctl 2， 这 样 具体 的 设备 只 要 定义 其 自身 相关 的 控制 接口 函数 即 可 。 当 然 驱 动 也 可 以 完 


2 























新 定义 自己 的 ioctl RAC IR HE EN to EERE. REET RIE, 
由 于 视频 设备 的 复杂 度 高 ， 标 准 的 ioctl 操作 无 法 履 盖 到 所 有 的 设备 ， 设 备 还 需要 能 对 























一 定 范围 的 量 进行 控制 的 接口 ， 而 且 还 要 提供 一 定 的 扩展 性 来 使 得 应 用 层 能 够 对 设备 特殊 人 参 
数 进行 控制 ， 男 外 还 需要 能 从 设备 中 获得 特殊 的 事件 信息 。 视 频 驱 动 框架 也 考虑 到 这 两 种 需 


求 
, 











并 提供 了 解决 方法 。 
首先 ， 看 一 下 设备 特殊 控制 的 解决 方法 ， 该 功能 不 仅 需要 对 单一 功能 的 设备 进行 支持 ， 

















当 设 备 有 多 个 功能 模块 的 时 候 ， 也 需要 能 够 支持 。 之 前 在 分 析 音 频 设备 的 时 候 看 到 ， 应 用 层 
只 有 一 个 控制 接口 ， 这 样 可 以 将 所 有 的 控制 都 加 入 到 该 接口 中 。 但 是 对 视频 设备 并 不 完全 适 


用 ， 














主要 是 因为 视频 设备 的 控制 流 和 数据 流 在 对 应 用 层 的 接口 video_device 中 很 难 完 全 分 离 ， 





而 且 某 些 设备 会 有 多 个 数据 流入 口 或 者 出 口 ， 这 样 对 一 个 视频 设备 来 说 ,会 有 多 个 针对 应 用 层 
的 video. device 实体 以 及 多 个 视频 文件 ， 但 是 在 设备 参数 的 控制 方面 最 好 还 是 有 单一 的 控制 流 ， 

















这 就 要 求 多 个 功能 模块 的 控制 部 分 能 够 统一 到 一 起 进行 管理 。 
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这 些 控制 的 统一 管理 是 由 结构 v412_ctrl_handler 来 完成 的 。 下 面 来 看 一 下 细节 ， 


struct v4l2_ctrl_handler f 
struct mutex lock; 
// 实 际 控制 元 素 的 链表 
struct list_head ctrls; 
// 用 于 控制 元 素 排 序 的 链表 


struct list_head ctrl_refs ; 


























struct v412_ctrl_ref * cached; 
struct v412_ctrl_ref * * buckets; 
ul6 nr_of_buckets ; 


int error; 


E 








而 实际 的 控制 元 素 是 由 struct v412_ctrl 来 表示 的 ， 其 中 包含 控制 值 的 类 型 、 范 围 、 属 性 
和 操作 接口 等 信息 。 操 作 接口 由 struct v412_ctrl_ops 来 表示 ， 定 义 的 操作 接口 内 容 如 下 : 








struct v412_ctrl_ops| 
/获得 控制 值 
int( * g volatile ctrl) (struct v412_ctrl * ctrl) ; 
// 测 试 控制 值 是 否 有 效 
int( * try_ctrl) (struct v412_ctrl * ctrl) ; 
设置 控制 值 


int( * s_ctrl) (struct v412_ctrl * ctrl) ; 





ls 





内 核 通过 ioctl 命令 对 控制 进行 操作 ， 相 关 的 命令 具体 包括 : 


VIDIOC_QUERYCTRL, VIDIOC_QUERYMENU, VIDIOC_G_CTRL, VIDIOC_S_CTRL, VIDIOC_G_ 
EXT_CTRLS, VIDIOC_TRY_EXT_CTRLS , VIDIOC_S_EXT_CTRLS 











以 上 是 应 用 层 的 操作 接口 ， 驱 动 添加 控制 元 素 框架 也 提供 了 相应 的 接口 。 首 先 要 初始 化 
控制 管理 实体 ， 通 过 v412_ctrl_handler_init 来 完成 。 





int v4l2_ctrl_handler_init( struct v412_ctrl_handler * hdl, unsigned nr. of controls hint) ; 





控制 实体 系统 提供 了 几 种 添加 的 接口 函数 ， 具 体 如 下 : 


struct v412_ctrl * v412_ctrl_new_std( struct v412_ctrl_handler * hdl, 

const struct v412_ctrl_ops * ops,u32 id,s32 min,s32 max,u32 step,s32 def); 
struct v412_ctrl * v412_ctrl_new_std_menu( struct v412, ctrl, handler * hdl, 

const struct v412_ctrl_ops * ops,u32 id,s32 max,s32 mask ,s32 def) ; 
struct v412_ctrl * v412_ctrl_new_custom( struct v412_ctrl_handler * hdl, 


const struct v412_ctrl_config * cfg, void * priv) ; 
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系统 提供 了 一 些 标准 的 TD 来 表示 相应 的 控制 元 素 ， 例 如 : 


#define V4L2_CID_BRIGHTNESS (V4L2_CID_BASE +0) 
#define V4L2_CID_CONTRAST ( V4L2_CID_BASE +1) 
#define V4L2_CID_SATURATION ( V4L2_CID_BASE +2) 
#define V4L2_CID_HUE ( V4L2_CID_BASE +3) 

#define V4L2_CID_AUDIO_VOLUME ( V4L2_CID_BASE +5) 
#define V4L2_CID_AUDIO_BALANCE ( V4L2_CID_BASE +6) 
#define V4L2_CID_AUDIO_BASS ( V4L2_CID_BASE +7) 
#define V4L2_CID_AUDIO_TREBLE (VAL2 CID BASE +8) 


以 上 只 是 很 少 的 一 部 分 ， 可 见 控 制 包含 各 种 与 设备 相关 的 部 分 ， 包 括 视频 、 图 像 调整 、 
编 解码 、 音 频 等 各 个 方面 ， 这 些 都 是 设备 的 需要 。 

框架 还 提供 了 对 所 有 控制 元 素 统一 设置 的 接口 v412, ctrl. handler. setup 来 方便 设置 操作 。 
下 面 举 一 个 DM3730 中 ISP 驱动 的 例子 看 控制 接口 是 如 何 使 用 的 。 














v412_ctrl_handler_init( &prev -> ctrls,3) ; 

v412_ctrl_new_std( &prev -> ctrls , &preview_ctrl_ops , V4L2_CID_BRIGHTNESS, 
ISPPRV_BRIGHT_LOW , ISPPRV_BRIGHT_HIGH, 
ISPPRV_BRIGHT_STEP , ISPPRV_BRIGHT_DEF) ; 

v412_ctrl_new_std( &prev -> ctrls , &preview_ctrl_ops , V4L2_CID_CONTRAST, 
ISPPRV_CONTRAST_LOW , ISPPRV_CONTRAST_HIGH, 
ISPPRV_CONTRAST_STEP, ISPPRV_CONTRAST_DEF) ; 

v412_ctrl_handler_setup( &prev -> ctrls) ; 

sd —> ctrl_handler = &prev -> ctrls; 


这 里 prev 是 ISP 中 的 一 个 子 设备 模块 ， 最 终 会 通过 v412_ctrl_add_handler 将 其 包含 的 控 
制 元 素 加 入 到 ISP 设备 中 统一 管理 ， 而 在 针对 应 用 层 管理 实体 video device 的 注册 函数 中 会 
将 其 v412_ctrl_handler 指针 指向 v412_device 相同 的 v412_ctrl_handler 实体 这 样 就 完成 了 统 
一 的 管理 。 

另 一 部 分 针对 应 用 层 的 功能 是 事件 的 处 理 ， 这 部 分 功能 需要 看 一 下 v412_fh 结构。 














struct v412_ fh} 
struct list_head list; 
struct video_device * vdev; 


struct v412_events * events ;/ * events, pending and subscribed * / 


| 


v412. events 中 是 所 有 事件 的 管理 实体 ， 下 面 来 看 一 下 详细 的 内 容 : 


struct v412_events | 
// 等 待 事件 的 等 待 队列 


wait_queue_head_t wait; 
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// 管 理 注册 的 关注 设备 的 事件 队列 























struct list_head subscribed ; / * Subscribed events * / 

下面 是 管理 内 核 中 设备 产生 事件 队列 

struct list_head free ; / * Events ready for use * / 

struct list_head available; / * Dequeueable event * / 
unsigned int navailable ; 

unsigned int nallocated ; / * Number of allocated events * / 
u32 sequence ; 


l; 


其 操作 方式 是 应 用 层 注册 需要 关注 哪些 事件 ， 而 内 核 会 对 产生 的 事件 加 入 队列 进行 和 
理 ， 并 在 应 用 要 获得 时 将 事件 的 详细 信息 上 报 。 有 具体 的 事件 是 由 vAD. event 定义 ， 内 容 
如 下 : 


} om 


m 


struct v412, event | 
ERU type; 
union | 


struct v412. event. vsync vsync; 


. u8 data[ 64 | ; 
ju; 
__u32 pending; 
__u32 sequence ; 
struct timespec timestamp ; 
ERU? reserved| 9 | ; 


| 





框架 提供 了 相关 的 操作 接口 ， 具 体 如 下 : 


int v412_event_init(struct v412_fh * fh) ; 

int v412. event, alloc( struct v412. fh * fh, unsigned int n) ; 

void v412. event, free( struct v412. fh * fh) ; 

int v412. event, dequeue( struct v412. fh * fh, struct v412_event * event, int nonblocking) ; 
void v412. event, queue( struct video. device * vdev , const struct v412. event * ev) ; 

int v412. event, pending( struct v412_fh * fh) ; 

int v412. event, subscribe( struct v412. fh * fh, struct v412. event, subscription * sub) ; 


int v412. event, unsubscribe( struct v412. fh * fh , struct v412, event, subscription * sub) ; 





另外 内 核 提供 了 标准 的 ioctl 命令 VIDIOC, DQEVENT, VIDIOC, SUBSCRIBE, EVENT 和 
VIDIOC_UNSUBSCRIBE_EVENT 来 完成 这 方面 的 功能 。 
通过 以 上 的 分 析 ，v412_fh 起 到 容器 的 功能 ， 既 然 是 容器 应 该 可 以 承担 更 多 功能 ， 最 新 
的 内 核 已 经 包含 了 w12_ctrl_handler， 将 控制 功能 包含 进来 ， 这 样 的 实现 更 合理 。v412_ 生 就 
完全 包含 了 对 应 用 层 的 功能 。 
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2. 设备 层次 管理 





前 面部 分 主要 涉及 视频 驱动 框架 中 对 应 用 层 接口 实体 的 管理 ， 框 架 还 需要 提供 实际 设备 





的 管理 层 。 对 特定 的 视频 设备 ， 框 架 的 管理 实体 是 v412_device。 


struct v412_device| 








// 设 备 模型 的 关联 ,通常 关联 到 父 设备 的 device 如 platform device 中 的 device 


struct device * dev; 

#if defined( CONFIG_MEDIA_CONTROLLER ) 
// 对 设备 内 拓扑 及 连接 的 管理 
struct media_device * mdev; 

#endif 
/ * used to keep track of the registered subdevs * / 
// 子 设备 的 链表 
struct list_head subdevs; 
// 驱 动 使 用 的 锁 
spinlock_t lock; 








/ * unique device name, by default the driver name + bus ID * / 


char name[ V4L2_DEVICE_NAME_SIZE] ; 
/ * notify callback called by some sub — devices. * / 
// 视 频 设备 内 部 子 设备 间 的 通知 操作 接口 ,主要 


void( * notify) (struct v412_subdev * sd, 























ads 
ad 











unsigned int notification, void * arg) ; 
/ * The control handler. May be NULL. */ 
// 设 备 所 有 的 控制 接口 ,对 应 用 层 的 控制 


struct v412_ctrl_handler * ctrl_handler; 





























/ * BKL replacement mutex. Temporary solution only. * / 


struct mutex ioctl_lock; 


l; 


v412_device 是 对 整个 视频 设备 的 管理 实体 ， 其 中 可 能 包含 





于 红外 控制 恬 等 外 部 











件 通知 








ur 








多 个 子 功 能 模块 ， 而 这 些 子 





功能 模块 会 作为 子 设 备 加 入 到 视频 设备 中 进行 管理 ， 从 结构 中 可 见 视 频 设备 管理 实体 主要 是 
管理 功能 ， 并 不 包含 操作 接口 ， 所 以 这 里 偏重 于 逻辑 管理 ， 具 体 功能 的 操作 则 由 子 设备 来 完 











成 ， 视频 框架 中 对 于 子 设备 进行 管理 ， 细 节 如 下 : 





struct v412_subdev| 
/设备 内 部 拓扑 的 节点 ,其 中 还 会 管理 连接 
struct media_entity entity; 
/列表 连接 子 设备 


struct list_head list; 





struct module * owner; 
// 标 记 子 设备 特点 
u32 flags; 
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// 标 记 顶 层 设备 

struct v412_device * v412. dev; 

// 设 备 操作 接口 

const struct v412. subdev. ops * ops; 

/ * The control handler of this subdev. May be NULL. * / 
/控制 接口 


struct v412_ctrl_handler * ctrl_handler; 





/ * name must be unique * / 

char name| VAL2. SUBDEV. NAME SIZE | ; 

/ * can be used to group similar subdevs , value is driver — specific * / 
// 用 于 驱动 标记 一 组 子 设备 

u32 erp_id; 




















a 


/ * pointer to private data * / 
// 以 下 是 用 于 驱动 标记 自身 的 管理 实体 


void * dev_priv; 





void * host_priv; 
/ * subdev device node * / 
// 子 设备 也 可 以 有 对 应 用 层 的 接口 


struct video_device devnode; 





unsigned int initialized ; 
/ * number of events to be allocated on open * / 
/对 于 应 用 层 事件 的 数目 


unsigned int nevents ; 

















| 








对 子 设备 特点 ， 系 统 提供 了 以 下 说 明 : 





#define V4L2_SUBDEV_FL_IS_I2C (1U ««0) 
#define V4L2_SUBDEV_FL_IS_SPI (1U ««1) 
#define VAL2. SUBDEV. FL HAS DEVNODE (1U ««2) 
#define VAL2. SUBDEV. FL HAS. EVENTS (1U ««3) 











前 面 两 个 是 总 线 接口 ， 后 面 两 个 是 设备 针对 应 用 层 的 特点 ， 分 别 表示 对 应 用 层 的 接口 设 
备 文件 和 对 应 用 层 的 事件 ， 这 样 系统 会 根据 这 些 设 置 做 相应 的 操作 。 子 设备 为 什么 也 需要 设 
备 文件 接口 呢 ? 这 是 由 于 视频 设备 中 很 多 子 功 能 模块 同样 需要 应 用 层 操 作 ， 如 图 像 的 统计 模 
块 。 由 于 特殊 事件 的 存在 ， 也 需要 应 用 层 进行 相应 的 处 理 ， 设 备 文件 是 最 直接 的 方法 ， 在 设 
备 文 件 注册 时 系统 会 对 这 种 子 设备 的 文件 名 做 特殊 处 理 ， 以 进行 区 分 。 

子 设备 驱动 相关 的 操作 接口 如 下 : 






































struct v412_subdev_ops | 
const struct v412_subdev_core_ops * core; 


const struct v412_subdev_file_ops * file; 
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const struct v412. subdev. tuner. ops * tuner; 


const struct v412. subdev. audio. ops * audio; 
const struct v412. subdev., video. ops * video; 
const struct v412. subdev. vbi. ops * vbi; 
const struct v412. subdev. ir ops * ir; 
const struct v412. subdev. sensor. ops * sensor; 


const struct v412. subdev. pad, ops * pad; 


E 








从 中 可 见 ， 视 频 子 设备 的 操作 是 多 种 多 样 的 ， 设 备 驱动 可 以 根据 自身 的 特点 选择 合适 的 
操作 接口 进行 设置 。 由 于 调用 子 设备 的 接口 比较 复杂 ， 视 频 驱 动 框架 提供 了 简易 的 宏 方 便 接 
口 调用 ,具体 如 下 : 














#define v412_subdev_call(sd,o,f, args... ) \ 
(! (sd)? -ENODEV :(( (sd) -»ops-»0o &&(sd) -»ops-»0o-»f)? \ 
(sd) -> ops -> o —>f( (sd) , ##args) : - ENOIOCTLCMD) ) 


具体 调用 如 : vAI2, subdev. call(sd,core,g chip. ident, &chip) ; 
这 些 操作 接口 可 以 在 内 核 中 使 用 ， 另 外 也 允许 应 用 层 对 一 些 接口 使 用 ， 具 体 的 实现 方法 
需要 先 来 看 看 子 设备 的 注册 接口 v412_device_register_subdev， 详 细 的 分 析 如 下 .、 








int v412_device_register_subdev( struct v412_device * v412_dev， 
struct v412_subdev * sd) 
| 
#if defined( CONFIG_MEDIA_CONTROLLER ) 
struct media_entity * entity = &sd —> entity; 
#endif 
struct video_device * vdev; 


int err; 


/ * Check for valid input * / 

// 检 查 操作 

if( v412, dev == NULL || sd == NULL || ! sd -> name[ 0] ) 
return — EINVAL; 


/ * Warn if we apparently re — register a subdev * / 


WARN_ON(sd -> v4. dev != NULL) ; 


if( ! try_module_get(sd —» owner) ) 
return - ENODEV ; 


/ ** This just returns 0 if either of the two args is NULL * / 
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// 首 先 将 控制 元 素 加 入 整体 设备 进行 管理 
err = v412_ctrl_add_handler( v412_dev -> ctrl_handler,sd —» ctrl_handler) ; 
if( err) 
return err; 
#if defined( CONFIG. MEDIA, CONTROLLER ) 
/ * Register the entity. * / 
if( v412_dev -> mdev) | 
// 注 册 进 拓扑 及 连接 管理 中 
err = media_device_register_entity( v412_dev -> mdev, entity) ; 
if( err <0) | 


module. put( sd —» owner) ; 

















return err; 


| 
#endif 


// 加 入 到 整体 设备 v412_dev 进行 设备 管理 
sd —>v4l2_dev = v4I2. dev; 

spin, lock( &v412_dev -> lock) ; 

list, add. tail( &sd —> list, &v412_dev -> subdevs) ; 
spin, unlock( &v412_dev -> lock) ; 











/ * Register the device node. * / 

// devnode 就 是 video. device 

vdev = &sd —> devnode ; 

strlepy( vdev -> name, sd -> name, sizeof( vdev -> name) ) ; 

/注意 这 里 使 用 的 是 parent 而 不 是 v4I2, dev ,这样 在 注册 时 不 会 设置 ctl handler 
vdev —> parent = v412. dev -> dev; 

// 视 频 文 件 的 操作 接口 

vdev —» fops = &v412_subdev_fops ; 


























vdev —> release = video. device, release empty ; 

if(sd —> flags & VAL2. SUBDEV. FL. HAS DEVNODE ) | 
// 只 有 声明 需要 创建 设备 文件 才 进 行 注 册 , 并 声明 是 VFL. TYPE SUBDEV 
err =__video_register_device( vdev, VFL_TYPE_SUBDEV, - 1,1, 


sd —> owner) ; 





if(err <0) | 
v412_device_unregister_subdev( sd) ; 


return err; 


| 
#if defined( CONFIG_MEDIA_CONTROLLER ) 
entity -> v4l. major = VIDEO. MAJOR ; 


entity —» v4l. minor = vdev —> minor; 
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#endif 


return 0; 


从 代码 中 可 见 ， 子 设备 文件 操作 接口 定义 为 412_subdev_fops， 这 就 是 转换 操作 的 入 口 ， 
具体 细节 如 下 : 





const struct v412_file_operations v412_subdev_fops = | 
. owner = THIS MODULE, 
. open = subdev. open, 
. unlocked, ioctl = subdev_ioctl , 
. release = subdev, close , 


. poll = subdev. poll, 
ls 


其 只 定义 了 部 分 操作 ，iocd 也 只 定义 了 一 部 分 操作 ， 主 要 的 操作 在 控制 流 上 ， 所 以 对 子 
设备 的 应 用 层 接口 应 该 主要 关心 控制 部 分 。 

对 于 不 同类 型 的 硬件 操作 接口 ， 如 了 C 和 SPI， 视 频 驱 动 框架 还 提供 了 简便 的 绑 定 接口 ， 
具体 如 下 : 











struct v412_subdev * v412_i2c_new_subdev( struct v412, device * v412, dev, 
struct i2c_adapter * adapter, const char * client, type, 
u8 addr,const unsigned short * probe. addrs) ; 

struct v412. subdev * v412_i2c_new_subdev_board( struct v412, device * v412, dev, 
struct i2c. adapter * adapter, struct i2c. board. info * info, 
const unsigned short * probe_addrs , int enable devnode); 

/ * Initialize an v412, subdev with data from an i2c. client struct * / 

void v4]2_i2c_subdev_init( struct v412, subdev * sd, struct i2c. client * client, 
const struct v412. subdev. ops * ops) ; 

/ * Return i2c client address of v412_subdev. * / 

unsigned short v412_i2c_subdev_addr( struct v412, subdev * sd) ; 


struct v412_subdev * v412. spi new, subdev( struct v412, device * v412. dev, 
struct spi, master * master, struct spi. board, info * info, 
int enable. devnode) ; 

/ * Initialize an v412, subdev with data from an spi, device struct * / 

void v412. spi, subdev. init( struct v412_subdev * sd struct spi. device * spi, 


const struct v412. subdev. ops * ops) ; 


整体 的 针对 物理 设备 的 管理 层次 与 组 织 就 通过 v412, device 和 v412_subdev 这 两 个 实体 来 
实现 了 。 
视频 驱动 系统 无 论 在 设备 文件 层面 还 是 物理 设备 管理 层面 都 建立 了 层次 关系 。 在 设备 文 
541 




















件 层 面子 设备 对 应 的 设备 文件 只 有 控制 特殊 事件 的 功能 ， 并 不 作为 数据 流 的 出 口 或 者 和 人口， 





而 通常 的 视 


流 的 出 入 口 ， 











频 功 能 设备 文件 会 是 数据 流 的 出 口 











3. 设备 内 拓扑 及 连接 管理 
以 上 解决 的 是 应 用 层 接口 以 及 设备 管理 层次 的 则 题 ， 但 是 设备 内 部 的 拓扑 以 及 连接 间 题 





或 者 入 口 ， 男 外 一 个 物理 设备 可 以 有 多 个 数据 








但 是 它们 都 会 关联 到 相同 的 物理 设备 管理 实体 v412_device。 














还 需要 解决 ， 
类 似 于 音 
等 操作 。 这 








而 且 要 提供 用 户 查 询 设置 的 接口 ， 





这 些 功能 由 media controller 部 分 完 








频 设 备 ， 视频 设备 内 部 的 通道 也 可 以 非常 复杂 ， 会 有 节点 进行 视频 流通 道 首 切 换 














作 的 接口 。 








这 就 需要 在 内 部 对 设备 的 拓扑 以 及 连接 进行 定义 和 管理 ， 在 外 部 还 要 提供 应 用 层 操 





视频 驱动 框架 对 这 部 分 的 管理 由 media, device 来 提供 ， 具 体 细节 如 下 : 


struct media_device | 


l; 


从 结构 分 析 中 可 见 ， 


/ * dev —> driver. data points to this struct. */ 


// 设 备 模 型 中 的 层次 关系 ,通常 SoC 设备 中 指向 platform 设备 中 的 device 


struct device * dev; 
// 对 应 用 层 的 管理 实体 


struct media_devnode devnode; 




















char model[ 32] ; 
char serial[ 40 ] ; 
char bus info[ 32]; 
u32 hw. revision; 


u32 driver version; 


// 当 前 下 一 个 管理 entity MA BS ID 号 
u32 entity_id; 
// 管 理 的 entity 链表 


struct list_head entities; 


/ * Protects the entities list * / 
spinlock_t lock; 
/ * Serializes graph operations. * / 


struct mutex graph_mutex; 








/通知 相关 实体 某 些 事件 的 发 生 ,使 得 模块 可 以 进行 相关 操作 


int( * link, notify) (struct media, pad * source, 














struct media, pad * sink , u32 flags) ; 


应 用 层 使 用 media, devnode 进行 管理 ， 而 在 内 部 则 通过 entity 链表 














进行 管理 。 先 来 看 看 内 部 的 管理 ， 内 部 具体 的 管理 实体 是 media_entity ， 详 细 内 容 如 下 : 


struct media_entity | 
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// 





于 entity 的 链表 





au 





struct list_head list; 











struct media_device * parent; / * Media device this entity belongs to * / 

// 1€ media device 中 的 ID 号 

u32 id; / * Entity ID, unique in the parent media device context * / 
const char * name; / * Entity name * / 

// 类 型 说 明 

u32 type; / * Entity type( MEDIA, ENTITY TYPE * ) * / 

u32 revision; / * Entity revision, driver specific * / 

unsigned long flags; / * Entity flass(MEDIA ENTITY FLAG * ) */ 

// group ID 用 于 驱动 的 操作 ,可 以 将 不 同 的 设备 分 组 

u32 group id; / ** Entity group ID * / 

// 模 块 的 数据 端点 的 数目 ,包括 输入 或 者 输出 端点 

ul6 num_pads; / * Number of input and output pads * / 

// 与 模块 相关 的 连接 数目 ,包括 输入 和 输出 的 连接 

ul6 num_links; / * Number of existing links, both enabled and disabled * / 
ul6 num, backlinks; / * Number of backlinks * / 

ul6 max links; / * Maximum number of links * / 

/端点 的 信息 

struct media_pad * pads; / * Pads array ( num, pads elements) * / 

/连接 的 信息 

struct media_link * links; / * Links array(max_links elements) * / 








// 该 模块 的 操作 接口 ,主要 是 建立 连接 时 的 设置 


const struct media_entity_operations * ops; / * Entity operations * / 























/该 模块 的 当前 数据 流 数 目 
































int stream_count; / * Stream count for the entity. * / 
/该 模块 的 引用 计数 ,通常 用 于 电源 管理 操作 
int use_count; / * Use count for the entity. * / 


























// 说 明 entity 具体 属于 哪个 数据 通道 ,由 驱动 进行 管理 ,通常 是 在 
// 操 作 点 (如 video_device) 所 属 的 pipeline 


struct media_pipeline * pipe; / * Pipeline this entity belongs to. */ 


























// 这 里 是 具体 设备 的 信息 ,从 中 可 见 media controller WH EY 


union | 











FH 


/ * Node specifications * / 
struct | 

u32 major; 

u32 minor; 
\ v4l; 


struct | 
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u32 major; 
u32 minor; 
| fb; 
struct | 
u32 card; 
u32 device; 
u32 subdevice; 
| alsa; 


int dvb; 


/ * Sub — device specifications * / 
/ * Nothing needed yet * / 
s 
ls 


实际 使 用 时 media, entity HRA fk E PES IA P, nz mi yr IL video device 和 v412_subdev 
中 都 包含 了 media_entity ， 由 于 它们 都 涉及 连接 与 管理 。 通 过 type 来 区 分 entity 的 类 型 EL 
分 类 如 下 : 





#define MEDIA_ENTITY_TYPE_DEVNODE 
#define MEDIA_ENTITY_TYPE_DEVNODE_V4L 
#define MEDIA ENTITY TYPE DEVNODE FB 
#define MEDIA ENTITY TYPE DEVNODE ALSA 
#define MEDIA ENTITY TYPE DEVNODE DVB 


#define MEDIA ENTITY TYPE VAL2 SUBDEV 

#define MEDIA ENTITY TYPE VAL2 SUBDEV SENSOR 
#define MEDIA ENTITY TYPE VAL2 SUBDEV FLASH 
#define MEDIA ENTITY TYPE VAL2 SUBDEV LENS 























iX devnode zr 1 Fr FE BB Sz P PR AY entity, Ti subdev XIR x PARA AY 
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另外 entity 还 包含 端点 以 及 连接 的 属性 ， 这 些 属性 由 下 面 的 结构 进行 管理 : 














struct media, pad | 


// Br Ji entity 














struct media, entity * entity; / * Entity this pad belongs to * / 

// entity 中 pad 的 编号 

ul6 index; / * Pad index in the entity pads array * / 
/人 /属性 

unsigned long flags; / * Pad flags( MEDIA, PAD FLAG. * ) */ 
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struct media, link | 


/连接 中 的 数据 源 端 点 














struct media_pad * source; / * Source pad * / 

// 连 接 中 的 数据 目的 端点 

struct media_pad * sink; / * Sink pad * / 

struct media, link * reverse; / * Link in the reverse direction * / 

// 属 性 

unsigned long flags; / * Link flags( MEDIA. LINK FLAG * ) * / 


| 


这 些 端点 以 及 连接 也 有 属性 ， 相 应 的 属性 如 下 : 


#define MEDIA_PAD_FLAG_INPUT (1 <<0) 
#define MEDIA PAD FLAG OUTPUT (1««1) 
#define MEDIA LINK FLAG. ENABLED (1««0) 
#define MEDIA LINK FLAG. IMMUTABLE (1««1) 
#define MEDIA LINK FLAG. DYNAMIC (1««2) 


框架 层 还 提供 一 些 函 数 对 这 些 管 理 实体 进行 操作 ， 相 关 的 接口 及 说 明 如 下 : 





//entity 的 初始 化 与 销毁 操作 
int media_entity_init( struct media, entity * entity ,ul6 num, pads, 
struct media. pad * pads, ul6 extra, links) ; 


void media, entity, cleanup( struct media, entity * entity) ; 





// 连 接 创 建 操作 
int media_entity_create_link(struct media, entity * source ,ul6 source pad, 
struct media, entity * sink ,ul6 sink pad,u32 flags) ; 


int media entity. setup. link( struct media, link * link ,u32 flags) ; 





int media, entity. setup. link( struct media, link * link ,u32 flags) ; 


// 连 接 查 找 操作 
struct media, link * media, entity find link( struct media, pad * source, 
struct media, pad * sink) ; 


struct media, pad * media, entity remote, source( struct media, pad * pad) ; 


// entity 使 用 计数 操作 
struct media_entity * media_entity_get( struct media_entity * entity) ; 


void media_entity_put( struct media_entity * entity) ; 


// ih UJ RROS ME 


void media, entity. graph walk start( struct media, entity. graph * graph, 
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struct media_entity * entity) ; 


struct media_entity * media_entity_graph_walk_next( struct media_entity_graph * graph) ; 





/数据 流 相 关 属 性 设置 


void media_entity_pipeline_start( struct media, entity * entity , struct media, pipeline * pipe) ; 


void media, entity, pipeline, stop( struct media, entity * entity) ; 
// entity 接口 函数 调用 的 宏 


#define media_entity_call( entity , operation, args. . . ) 





(( (entity) -> ops &&( entity) —» ops —> operation) ? 


\ 


(entity) —» ops —> operation( ( entit: 


y) ,##args) : - ENOIOCTLCMD ) 





这 里 主要 是 初始 化 、 设 置 和 遍历 ， 以 及 流 





属性 设置 等 操作 ， 实 际 的 设备 操作 驱动 会 通过 





entity JRA entity 实际 管理 的 实体 进而 执行 相关 的 操作 。 可 见 在 内 部 media controller 的 实 
体 主要 起 到 对 输入 输出 端点 进行 抽象 ， 对 连接 进行 抽象 ， 并 将 端点 和 连接 进行 管理 ， 由 于 其 
乱入 到 实际 的 设备 管理 中 ， 所 以 可 以 进行 由 抽象 到 具体 的 转换 ， 从 而 进行 实际 的 操作 。 对 抽 
象 和 具体 之 间 的 转换 ， 视 频 驱 动 框架 也 提供 了 相关 的 宏 ， 细 节 如 下 : 








#define media_entity_to_v412_subdev( ent) container_of( ent, struct v412_subdev, entity ) 


#define media_entity_to_video_device( entity) \ 


container, of( entity , struct video. devi 








ce , entity ) 


接 下 来 看 看 应 用 层 接 口 管理 是 如 何 实现 的 。 相 应 的 管理 实体 由 media, devnode 来 承担 ， 


细节 如 下 : 


struct media_devnode | 


/ * device ops * / 








/为 将 来 扩展 提供 的 设备 相关 的 操作 接口 ,目前 使 用 统一 提供 的 接口 


const struct media, file operations * fops ; 


/ * sysfs * / 

/设备 模型 实体 
struct device dev; 
ERB 


struct cdev cdev; 





struct device * parent; 


/ * device info * / 
// 了 于 设备 号 

int minor; 
/访问 属性 


unsigned long flags; 
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/ * media device * / 


/ * character device * / 


/ * device parent * / 


/ * Use bitops to access flags * / 


hus 





/ * callbacks * / 


void( * release) ( struct media, devnode * mdev) ; 





性 还 是 很 简单 的 ， 也 留 了 一 定 的 扩展 余地 。 下 面 看 看 相应 的 注册 管理 函数 的 实现 。 


int. must check media, devnode, register( struct media_devnode * mdev) 
int minor; 


int ret ; 


/ * Part 1; Find a free minor number * / 
mutex, lock ( &media, devnode lock); 
/首先 查找 子 设备 号 
minor = find, next, zero. bit( media, devnode nums,0,MEDIA, NUM, DEVICES) ; 
if( minor == MEDIA, NUM, DEVICES) | 
mutex, unlock ( &media, devnode. lock) ; 
printk( KERN. ERR "could not get a free minor Wn" ) ; 
return — ENFILE ; 














set, bit( mdev -> minor, media devnode nums); 


mutex, unlock ( &media devnode lock); 


// 设 置 子 设备 号 


mdev —> minor = minor; 


/ * Part 2; Initialize and register the character device * / 
/人 /注册 字符 设备 
cdev_init( &mdev -> cdev ,&media_devnode_fops) ; 


mdev -> cdev. owner = mdev -> fops —» owner; 


/注册 字符 设备 
ret = cdev_add( &mdev -> cdev, MKDEV( MAJOR ( media, dev, t) , mdev -> minor) ,1 ) ; 
if( ret «0) | 

printk( KERN. ERR "26s; cdev_add failed\n" , — func ); 


goto error; 


/ * Part 3; Register the media device * / 
// 设 置 设 备 模型 实体 
mdev —> dev. bus = &media_bus_type; 
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mdev -> dev. devt = MKDEV ( MAJOR ( media, dev. t) ,mdev -> minor) ; 
mdev —> dev. release = media, devnode. release; 
if( mdev -> parent ) 
mdev —> dev. parent = mdev —> parent; 
// 设 置 设备 文件 名 
dev_set_name( &mdev -> dev," media% d" , mdev -> minor) ; 
/注册 到 设备 模型 ,依据 这 些 信 息 产生 设备 文件 
ret = device_register( &mdev -> dev) ; 
if( ret <0) | 
printk( KERN, ERR "%s; device register failed\n" ,__func__) ; 

















goto error; 


/ * Part 4; Activate this minor. The char device can now be used. * / 
// 设 置 已 经 注册 
set_bit( MEDIA. FLAG. REGISTERED , &mdev -> flags) ; 


return 0; 


error: 


cdev_del( &mdev -> cdev ) ; 
clear bit( mdev -> minor, media, devnode. nums ) ; 


return ret ; 





可 见 media controller 会 创建 单独 的 设 备 文 件 , 并 提供 统一 的 文件 操作 接 口 media, dev- 
node. fops 用 以 与 应 用 层 交 互信 息 。 框 架 提供 了 进一步 封装 的 接口 media. device, register 用 于 
整体 的 管理 实体 media_device 注册 。 




















int, must check media_device_register( struct media, device * mdev) 


| 


int ret; 


if( WARN_ON(mdev -» dev == NULL || mdev -> model[0 ] ==0) ) 
return — EINVAL; 


mdev —> entity id =1; 
INIT_LIST_HEAD( &mdev -> entities) ; 
spin_lock_init( &mdev —> lock) ; 


mutex, init( &mdev —» graph_mutex) ; 


/ * Register the device node. * / 


//media 设备 操作 的 接口 
mdev —> devnode. fops = &media_device_fops ; 
mdev —> devnode. parent = mdev —> dev; 
mdev —> devnode. release = media, device, release ; 
// 设 备 节点 注册 
ret = media_devnode_register( &mdev -> devnode) ; 
if(ret <0) 

return ret; 
/创建 属性 文件 
ret = device_create_file( &mdev -> devnode. dev,&dev_attr_ model ) ; 
if(ret <0) | 


media, devnode, unregister( &mdev -> devnode ; 














return ret; 


return 0; 


| 








可 见 操作 也 十 分 简单 ， 主 要 是 注册 了 实际 的 操作 接口 media_device_fops， 该 接口 支持 设 
备 文 件 操作 ， 具 体 如 下 : 


#define MEDIA_IOC_DEVICE_INFO _IOWR( M ,1,struct media, device, info) 
#define MEDIA, IOC. ENUM, ENTITIES .IOWR( M ,2,struct media, entity. desc) 
#define MEDIA. IOC. ENUM, LINKS _IOWR( M ,3,struct media, links enum) 
#define MEDIA, IOC. SETUP. LINK _IOWR( M ,4,struct media, link. desc ) 


通过 这 些 操作 就 可 以 实现 各 个 端点 能 力 的 查询 以 及 连接 的 建立 ， 实 现 整 个 系统 灵活 的 查 
询 与 控制 。 

4. 数据 流 

数据 流 是 视频 设备 操作 的 核心 。 其 中 包括 对 数据 操作 区 域 、 数 据 格式 等 ， 而 对 数据 的 操 
作 方 式 是 通过 buffer queue 来 进行 的 ， 每 次 操作 单个 buffer。 相 应 的 数据 流 操作 是 通过 ioctl 
命令 来 完成 的 ， 系 统 对 于 标准 的 视频 设备 文件 提供 的 与 数据 流 相 关 的 操作 命令 如 下 : 
































VIDIOC_REQBUFS :分 配 内 存 
VIDIOC_QUERYBUF: 42 VIDIOC_REQBUFS 中 分 配 的 数据 缓存 转换 成 物理 地 址 
VIDIOC_S_FMT: 设 置 数 据 buffer 的 格式 

VIDIOC_G_FMT: 读 取 数 据 buffer 的 格式 
VIDIOC_TRY_FMT: 验 证 格式 是 否 支 持 
VIDIOC_CROPCAP: 查 询 设备 侧 的 数据 范围 能 力 
VIDIOC_S_CROP: 设 置 设备 侧 的 数据 范围 
VIDIOC_G_CROP: 读 取 设 备 侧 的 数据 范围 
VIDIOC_QBUF: 把 数据 放 回 缓存 队列 交 给 设备 
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域 。 需 要 明确 的 是 format 是 针对 内 存 中 buffer 的 数据 格式 

















VIDIOC_DQBUF :把 数据 从 缓存 中 取出 交 给 应 用 层 
VIDIOC_STREAMON :启动 流 
VIDIOC_STREAMOFF :停止 流 











缓冲 buffer 的 类 型 由 枚 举 定义 为 以 下 的 类 型 . 


enum v412_buf_type | 


#if 1 


VAL2 BUF TYPE VIDEO CAPTURE 
VAL2 BUF TYPE VIDEO OUTPUT 

VAL2 BUF TYPE VIDEO OVERLAY 
VAL2 BUF TYPE VBI CAPTURE 

VAL2 BUF TYPE VBI OUTPUT 

VAL2 BUF TYPE SLICED VBI CAPTURE 
VAL2 BUF TYPE SLICED VBI OUTPUT 




















/ ** Experimental * / 


VAL2 BUF TYPE VIDEO OUTPUT OVERLAY =8, 





#endif 


区 


VAL2 BUF TYPE PRIVATE 


缓冲 的 内 存 分 配方 式 通过 枚 举 包含 以 下 的 类 型 ， 





enum v412_memory | 


E 


// 驱 动 分 配 空间 
V4L2_MEMORY_MMAP =1, 
// 应 用 层 分 配 空间 
V4L2_MEMORY_USERPTR =2, 
VAL2. MEMORY. OVERLAY =3, 


= 0x80, 


数据 流 的 具体 操作 与 其 类 型 以 及 内 存 分 配方 式 都 是 相关 的 ， 例 如 对 于 capture 缓冲 类 型 
来 说 ， crop 是 设置 图 像 源 的 取景 区 域 ; 而 对 于 output 缓冲 类 型 ， crop 是 设置 显示 图 像 的 区 


























进行 相关 的 范围 设置 ， 实 际 应 用 中 的 缩放 都 是 依据 这 些 参数 进行 的 ， 而 只 有 理 
明确 意义 才能 更 好 地 使 用 它们 。 在 内 存 分 配方 式 方面 对 数据 流 的 操作 也 是 有 影 
由 应 用 分 配 还 是 内 核 驱动 进行 分 配 ， 相 应 的 操作 也 是 不 同 的 ， 主 要 的 差别 是 在 分 配 内 存 以 及 
映射 操作 等 方面 。 























解 这 些 参 数 
响 的 ， 内 存 


属性 ，crop 是 根据 设备 侧 的 能 力 的 


的 


H 
JE 





视频 设备 视频 流 中 的 内 存 管理 是 一 个 复杂 的 过 程 ， 包 括 内 存 分 配 、 各 种 流程 以 及 状态 的 


管理 ， 还 有 了 映射 处 理 等 问题 ， 青 加 上 视频 设备 数据 格式 的 复杂 多 样 ( 如 yuv420sp 要 求 分 离 
的 内 存 块 ， 而 yuv422interleave 则 要 求 单 一 的 数据 块 ) ， 也 加 剧 了 相应 管理 的 复杂 性 。 
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内 核 为 了 降低 视频 设备 数据 流 开 发 的 难度 ， 








进行 了 多 种 技术 的 开发 ， 从 videobuf 到 


videobuf2, LAS CMA, DMA, BUF 等 都 是 为 了 提升 视频 设备 的 性 能 ， 并 降低 视频 设备 的 开 
发 难度 。 由 于 很 多 技术 还 比较 新 ， 在 驱动 中 还 没有 广泛 的 应 用 ， 所 以 这 里 并 不 进行 完整 的 详 
述 ， 只 是 对 videobuf2 以 及 相关 技术 进行 介绍 。 

videobuf2 开发 的 目的 是 为 驱动 提供 一 组 用 于 管理 streaming IO buffer 的 接口 。videobuf2 
实现 了 三 种 buffer 内 存 管理 模型 ， 分 别 如 下 : 

CD vmalloc buffer。 这 类 buffer 由 vmalloc( 、 在 内 核 空间 虚拟 地 址 上 是 连续 的 。 

(2) contiguous DMA buffers。 在 物理 内 存 上 ， 通 常人 硬件 设备 需要 在 连续 物理 地 址 空间 
上 执行 DMA 操作 。 

(3) S/G DMA puffers。 在 物理 内 存 上 是 不 连续 的 ， 如 果 硬 件 上 支持 scatter/gather DMA, 
驱动 可 以 使 用 DMA 进 和 操作 。 

具体 的 驱动 可 以 选择 这 三 种 的 一 种 方式 进行 管理 ， 由 于 每 种 管理 模型 都 提供 了 类 型 为 
vb2_mem_ops 的 操作 接口 ， 具 体内 容 如 下 : 



































struct vb2_mem_ops| 
// 分 配 video memory 
void * ( * alloc) (void * alloc_ctx , unsigned long size) ; 
// 通 知 buffer 不 被 使 用 了 
void ( * put) ( void * buf. priv) ; 
// 当 用 户 分 配 memory 类 型 时 ,获得 一 块 用 户 空间 memory 给 硬件 使 用 


void * ( * get, userptr) ( void * alloc_ctx, unsigned long vaddr, 














unsigned long size, int write) ; 
/通知 用 户 不 使 用 相应 空间 
void ( * put, userptr) ( void * buf. priv) ; 
// 返 回 buffer 的 内 核 地 址 空间 中 的 虚拟 地 址 
void * ( * vaddr) ( void * buf. priv) ; 
/返回 给 定 buffer 相关 的 特定 私有 数据 
void * ( * cookie) ( void * buf. priv) ; 
/返回 使 用 者 数目 
unsigned int ( * num, users) ( void * buf. priv) ; 
// ESL buffer 的 应 用 层 映射 


int ( * mmap) ( void * buf_priv, struct vm, area, struct * vma) ; 





























E 


该 操作 接口 定义 了 内 存 分 配 与 管理 的 标准 接口 ， 通 过 为 queue 填 人 不 同 的 操作 接口 就 可 
以 选择 不 同 的 管理 模型 。 
解决 了 整体 上 的 内 存 管理 方式 ， 相 应 的 buffer 在 不 同 状态 ,设备 可 能 需要 有 不 同 的 操 
作 ， 为 此 框架 为 驱动 提供 对 于 buffer 在 不 同 状态 进 和 a eee a 




















struct vb2_ops | 
// NIDIOC, REQBUFS fil VIDIOC_CREATE_BUFS 时 调用 
int( * queue, setup) ( struct vb2. queue * q,const struct v412, format * fmt, 


unsigned int * num buffers , unsigned int * num planes, 
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unsigned int sizes| | ,void * alloc_ctxs[ ] ) ; 
// 锁 的 操作 接口 ,主要 是 保证 buffer queue 操作 的 一 致 性 
// 在 ioctl 需要 等 待 一 个 新 的 buffer 之 前 调用 , 这 里 释放 可 能 会 用 到 的 锁 
void( * wait, prepare) (struct vb2_queue * q) ; 
// 在 等 待 结束 开始 操作 时 通常 是 唤醒 后 调用 ， 


void( * wait, finish) ( struct vb2_queue * q) ; 





















































limi 





新 获得 相关 的 锁 


//buffer 的 操作 接口 
// 当 由 驱动 分 配 时 ,在 分 配 时 调用 ; 当 由 应 用 层 分 配 时 ,在 获得 一 个 buffer 时 调用 
// 驱 动 可 以 进行 附加 的 初始 化 

int( * buf init) (struct vb2_buffer * vb) ; 

// 每 次 buffer 从 应 用 层 加 入 videobuf2 队列 时 调用 ,驱动 可 以 执行 相关 操作 

int( * buf prepare) (struct vb2_buffer * vb) ; 

// 481K buffer 从 videobuf2 队列 dequeue 到 应 用 层 时 调用 ,驱动 可 以 执行 相关 操作 
int( * buf finish) (struct vb2_buffer * vb) ; 

// Ej buf init 对 应 的 释放 时 调用 ,驱动 可 以 进行 附加 的 操作 

void( * buf. cleanup) (struct vb2_buffer * vb) ; 
































//stream 状态 变化 操作 接口 
//queue 转 和 人 streaming 状态 时 的 接口 ,硬件 有 对 buffer 数目 的 需求 时 ， 
// 驱 动 可 能 需要 在 进入 streaming 时 进行 相关 操作 

int( * start, streaming) (struct vb2_queue * q, unsigned int count) ; 

// 停 止 stream ,驱动 应 将 所 有 的 buffer 返回 给 videobuf2 


int( * stop. streaming) (struct vb2_queue * q) ; 











// 驱 动 的 buffer 队列 接口 ,从 videobuf2 队列 中 获得 buffer, 使 用 该 buffer 进行 
/实际 操作 
void( * buf_queue) (struct vb2_buffer * vb) ; 

E 


以 上 的 接口 分 别 是 videobuf2 框架 需要 驱动 实现 的 接口 (根据 设计 某 些 接 口 可 以 不 实 
现 ) ， 框 架 层 更 多 的 是 对 buffer 的 操作 以 及 管理 提供 统一 的 操作 接口 ， 还 需要 将 buffer EA 
驱动 中 进行 实际 的 操作 ， 框 架 通 过 驱动 提供 的 buf. queue 接口 将 统一 管理 的 队列 转 入 驱动 进 
行 操作 ， 相 应 的 需要 将 buffer 从 驱动 转 入 框架 统一 管理 ,框架 提 供 了 接口 函数 vb2_buffer_ 
done 来 进行 该 操作 ， 了 驱动 也 需要 将 buffer 的 状态 信息 报告 给 框架 ,该 接口 在 驱动 操作 完 一 个 
buffer 后 使 用 。 

以 上 是 驱动 的 接口 ， 男 外 videobuf 框架 为 了 驱动 的 应 用 层 操 作 方 便 提供 了 标准 的 操作 
函数 接口 ， 具 体 如 下 : 


























int vb2_querybuf( struct vb2_queue * q, struct v412_buffer * b) ; 
int vb2_reqbufs( struct vb2_queue * q, struct v412_requestbuffers * req) ; 
int vb2_qbuf( struct vb2_queue * q,struct v412_buffer * b) ; 
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int vb2_dqbuf( struct vb2_queue * q, struct v412_buffer * b, bool nonblocking) ; 
int vb2_streamon( struct vb2_queue * q,enum v412_buf_type type); 
int vb2_streamoff( struct vb2_queue * q,enum v412_buf_type type) ; 
int vb2_mmap( struct vb2_queue * q, struct vm, area, struct * vma) ; 
unsigned int vb2_poll( struct vb2_queue * q, struct file * file, poll_table * wait) ; 
size t vb2_read( struct vb2_queue * q,char __user * data,size t count, 

loff_t * ppos, int nonblock) ; 
size_t vb2_write( struct vb2_queue * q,char __user * data,size_t count, 


loff_t * ppos, int nonblock) ; 





驱动 可 以 直接 在 ioctl 中 调用 相应 的 接口 ， 从 而 简化 操作 并 且 避 免 错误 。 
下 面 是 使 用 videobuf2 的 例子 ， 主 要 是 在 初始 化 时 的 操作 。 





q —> type = V4L2_BUF_TYPE_VIDEO_CAPTURE; 
q —> io. modes = VB2_MMAP; 
q —> drv. priv = handle; 





q —> ops = &iss video. vb2ops; 
q -> mem ops = &vb2_dma_contig_memops; 
q —> buf. struct, size = sizeof( struct iss. buffer) ; 


ret = vb2. queue, init( q) ; 








可 见 ， 这 类 统一 的 buffer queue 管理 ， 主 要 的 功能 是 在 应 用 层 到 驱动 层 之 间 对 buffer 
queue 以 及 buffer 的 操作 标准 化 ， 在 应 用 层 到 驱动 之 间 建 立 一 层 完整 的 、 健 壮 的 数据 管理 层 ， 
从 而 简化 驱动 的 开发 ， 避 人 免 错误 。 相 应 的 在 接口 设计 方面 ， 通 过 对 buffer 不 同 状态 的 细 化 为 
驱动 的 操作 保留 相应 的 接口 ， 从 而 提高 框架 的 适用 范围 ， 提 升 整个 系统 的 可 移植 性 以 及 稳 
定性 。 

无 论 怎样 ， 不 同 的 框架 单个 buffer 的 管理 实体 通常 是 v412_buffer 或 者 相应 的 变种 ， 相 应 
的 细节 如 下 : 





























struct v412_ buffer} 
//buffer 的 索引 号 


. u32 index; 
//buffer 的 类 型 

enum v412_buf_type type; 

. u32 bytesused ; 

. u32 flags; 

enum v4l2. field field; 
struct timeval timestamp ; 
struct v412_ timecode timecode; 
n9 sequence; 

// 内 存 的 分 配方 式 

enum v4l2_memory memory; 
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union { 


// 内 核 分 配 表示 偏 移 值 






































. u32 offset ; 
// 用 户 分 配方 式 表示 用 户 地址 
unsigned long userptr; 

im; 

. .u32 length; 

. .u32 input ; 

. u32 reserved ; 
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相应 的 信息 可 以 在 内 核 使 用 ， 也 可 以 在 应 用 层 使 用 ， 是 一 种 标准 的 结构 。 
关于 视频 驱动 的 数据 流 ， 还 有 一 部 分 视频 子 设备 相关 的 操作 。 具 体操 作 如 下 : 











#define VIDIOC_SUBDEV_G_FMT _IOWR( V , 4,struct v412, subdev. format ) 
#define VIDIOC SUBDEV. S FMT _IOWR( V , 5,struct v412, subdev. format ) 
#define VIDIOC SUBDEV. G. FRAME INTERVAL V 

_IOWR( V ,21 ,struct v412, subdev. frame, interval) 
#define VIDIOC. SUBDEV. S FRAME INTERVAL V 

_IOWR( V ,22,struct v412. subdev. frame, interval) 
#define VIDIOC SUBDEV ENUM MBUS CODE \ 

_IOWR( V , 2,struct v412, subdev. mbus, code, enum) 
#define VIDIOC SUBDEV. ENUM, FRAME SIZE V 

_IOWR( V ,74, struct v412. subdev. frame, size. enum ) 
#define VIDIOC SUBDEV. ENUM, FRAME INTERVAL V 

_IOWR( V ,75 ,struct v412. subdev. frame, interval, enum) 
#define VIDIOC. SUBDEV. G. CROP .IOWR( V ,59 struct v412, subdev. crop) 
#define VIDIOC. SUBDEV. S. CROP .IOWR( V ,60,struct v412, subdev. crop) 



































可 见 只 有 数据 格式 的 操作 ， 并 没有 对 流 的 操作 。 这 是 由 于 子 设备 通常 是 数据 流 中 的 一 个 
节点 ， 而 视频 设备 的 数据 出 口 或 者 入 口 是 对 应 于 内 存 中 的 buffer 的 ， 在 单纯 的 子 设备 中 并 没 
有 该 功能 ， 也 就 不 需要 进行 相关 的 操作 了 。 

从 整体 上 讲 ， 视 频 设备 的 数据 流 管理 的 主要 工作 就 是 保证 各 个 节点 格式 以 及 能 力 的 正确 
设置 ,并且 保 证 数据 的 正确 操作 和 人 处理 。 


6.4.3 ”视频 驱动 应 用 层 操 作 及 框架 适 配 


对 视频 应 用 来 说 ， 主 要 就 是 获取 视频 流 的 操作 。 下 面 以 操作 顺序 来 了 解 应 用 层 是 如 何 使 
用 视频 设备 的 。 该 实例 是 采集 设备 到 显示 设备 的 回 显 例子 ， 这 里 简化 了 代码 ， 只 列 出 采集 设 
备 相 关 的 操作 。 

首先 是 打开 视频 设备 : 
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int open, cam, device( int flag, int device) 


| 
char devnode[ 20 ] ; 


sprintf( devnode , " /dev/ video96 d" , device) ; 


return open( devnode , flag) ; 


接 下 来 是 对 数据 格式 的 控制 ; 


int cam_ioctl(int fd, char * pixFormat, char * size , char * sizeH ) 


| 


struct v412_format format; 


int ret =0; 


int index =0; 


/ * get the current format of the video capture * / 
format. type = V4L2_BUF_TYPE_VIDEO_CAPTURE; 
ret = ioctl (fd, VIDIOC_G_FMT, &format) ; 
if( ret <0) | 

perror( " VIDIOC_G_FMT" ) ; 


return ret; 





| 

// 根 据 参数 进行 分 别 率 设置 

if( | stremp( size," QQCIF" ) ) | 
format. fmt. pix. width 2 88; 
format. fmt. pix. height = 72; 

| else if( ! stremp( size, " SQCIF" ) ) | 
format. fmt. pix. width = 128; 
format. fmt. pix. height = 96; 


| else if 


// 根 据 传人 的 参数 进行 格式 设置 
if( ! stremp( pixFormat," YUYV" ) ) 

format. fmt. pix. pixelformat = V4L2_PIX_FMT_YUYV; 
else if( | stremp( pixFormat , " UYVY" ) ) 

format. fmt. pix. pixelformat = VAL2 PIX FMT UYVY; 
else if( | stremp( pixFormat , " RGB565" ) ) 

format. fmt. pix. pixelformat = V4L2_PIX_FMT_RGB565 ; 
else if( | stremp( pixFormat , " RGB555" ) ) 
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/ * set size & format of the video image * / 
/设置 格式 
ret = ioctl ( fd, VIDIOC_S_FMT , &format) ; 
if( ret <0) | 

perror( " VIDIOC S. FMT" ) ; 


return ret; 


/ * read back * / 
// 回 读 一 下 ,可 以 不 需要 
format. type = V4L2_BUF_TYPE_VIDEO_CAPTURE; 
ret = ioctl (fd, VIDIOC_G_FMT, &format) ; 
if( ret <0) | 
perror( " VIDIOC_G_FMT" ) ; 


return ret ; 











return 0; 


设置 帧 率 等 信息 : 


int setFramerate( int fd ,int framerate ) 


| 


struct v4l2_streamparm parm; 


int ret; 





parm. type = V4I2, BUF. TYPE, VIDEO. CAPTURE ; 
ret = ioctl ( fd, VIDIOC G. PARM , &parm) ; 
if( ret) | 

perror( " VIDIOC_G_PARM" ) ; 


return ret; 


parm. parm. capture. timeperframe. numerator = 1 ; 
parm. parm. capture. timeperframe. denominator = framerate ; 
ret = ioctl ( fd, VIDIOC_S_PARM,&parm) ; 
if( ret) | 
perror( " VIDIOC S PARM"); 


return ret; 


return 0; 





检查 设备 是 否 可 以 streaming: 








if( ioctl ( cfd, VIDIOC_QUERYCAP, &capability) <0) | 
perror( "cam VIDIOC_QUERYCAP" ) ; 
return - 1; 
| 
if( capability. capabilities & V4L2_CAP_STREAMING ) 
printf( " The driver is capable of Streaming! Wn" ) ; 
else | 
printf( " The driver is not capable of Streaming! \n" ) ; 


return - 1; 


对 buffer 进行 设置 . 





// 查 询 允 许 的 buffer 数目 
if(ioctl( cfd, VIDIOC_REQBUFS, &creqbuf) <0) | 
perror( "cam VIDEO_REQBUFS" ) ; 


return - 1; 





cbuffers = calloc( ereqbuf. count, sizeof( * cbuffers) ) ; 

/ * mmap driver memory or allocate user memory, and queue each buffer * / 

// 对 每 个 buffer 进行 设置 

for(i =0;i < creqbuf. count; ++1) | 
struct v412_buffer buffer; 





buffer. type = creqbuf. type; 

buffer. memory = creqbuf. memory ; 

buffer. index =i; 

// 获 得 相应 buffer 的 信息 

if(ioctl( cfd, VIDIOC_QUERYBUF, &buffer) <0) | 
perror( "cam VIDIOC_QUERYBUF" ) ; 


return — 1; 





| 

if(memtype == V4L2_MEMORY_USERPTR) | 
/应 用 层 分 配 设置 参数 
buffer. flags =0; 
/人 /采集 使 用 显示 分 配 的 buffer 


buffer. m. userptr = (unsigned int) vbuffers[ i]. start; 























buffer. length = vbuffers| i ]. length; 
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// 将 buffer 放 入 队列 进行 管理 
if(ioctl( cfd, VIDIOC_QBUF, &buffer) <0) | 
perror( "cam VIDIOC_QBUEF" ) ; 


return — 1; 








获得 buffer 并 进行 相关 操作 : 


//stream on 
if(ioctl( cfd, VIDIOC_STREAMON, &creqbuf. type) <0) | 
perror( "cam VIDIOC_STREAMON'" ) ; 


return - 1; 


/ * caputure 1000 frames or when we hit the passed nmuber of frames * / 
cfilledbuffer. type = creqbuf. type ; 
i=0; 
while( i < 1000) | 

/ * De - queue the next avaliable buffer * / 

// 获 得 capture 数据 

while( ioctl( cfd, VIDIOC_DQBUF, &cfilledbuffer) <0) 

perror( "cam VIDIOC_DQBUE" ) ; 
i++; 


// 这 里 可 以 进行 应 用 的 操作 或 者 相关 的 设置 
































if(i == count) | 
// 根 据 设 置 的 stream off 的 数目 ,停止 采集 
printf( " Cancelling the streaming capture... Wn" ) ; 
creqbuf. type = V4L2_BUF_TYPE_VIDEO_CAPTURE; 
if(ioctl( cfd, VIDIOC_STREAMOFF, &creqbuf. type) <0) f 
perror(" cam VIDIOC_STREAMOFF" ) ; 


return — 1; 











} 
printf ( " Done\n" ) ; 
break; 


if(i»23)| 
// 将 回 显 过 的 buffer 释放 
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cfilledbuffer. index = vfilledbuffer. index ; 
while(ioctl( cfd, VIDIOC_QBUF, &cfilledbuffer) <0) 
perror(" cam VIDIOC_QBUF" ) ; 


| 


最 后 就 是 释放 的 相关 操作 ， 基 本 就 是 之 前 操作 的 道 操作 ， 就 不 详 述 了 。 由 代码 可 见 ， 通 
过 用 户 分 配 buffer 的 方式 实现 输入 输出 共用 相同 的 buffer 空间 ， 从 而 实现 无 颖 连接 ， 并 市 省 
内 存 。 视 频 设备 框架 的 设计 是 灵活 的 ， 可 以 实现 各 种 复杂 的 功能 。 

视频 设备 在 Android 的 适 配 涉及 很 多 方面 ， 包 括 Surface Flinger, HW Composer 以 及 
Camera 等 ， 这 里 主要 以 Camera 设备 的 适 配 进 行 说 明 ， 为 其 他 部 分 涉及 太 多 框架 的 


aw 
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设备 的 适 配 同 样 需要 实现 HAL 层 ， 相 应 的 HAL 层 实 体 初 始 化 的 操作 如 下 : 


























int camera_device_open( const hw_module_t * module, const char * name, 


hw_device_t * * device) 


int rv 20; 

int num. cameras = 1; 

int cameraid ; 

VA1]2. camera, device t * camera, device = NULL; 


camera, device ops t** camera ops = NULL; 


if( name! 2 NULL) | 


cameraid = atoi( name) ; 


if( cameraid » num, cameras) 


| 
rv = - EINVAL; 


goto fail; 











//android 为 camera 设备 定义 的 抽象 的 管理 实体 和 操作 实体 分 别 是 


//camera_device 和 camera_device_ops_t, 这 里 需要 实体 化 



































camera, device = ( V412_camera_device_t * ) malloc( sizeof( * camera, device) ) ; 


if( ! camera, device) 

| 
ALOGE( " camera, device allocation fail" ) ; 
rv = - ENOMEM; 


goto fail; 
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camera, ops = ( camera, device, ops t * ) malloc( sizeof( * camera, ops) ) ; 
if( ! camera, ops) 
| 

ALOGE( "camera_ops allocation fail" ) ; 

rv = - ENOMEM; 

goto fail; 


memset ( camera, device, 0, sizeof( * camera, device) ) ; 


memset( camera, ops, 0, sizeof( * camera, ops) ) ; 


camera, device —» base. common. tag = HARDWARE DEVICE TAG; 
camera, device —> base. common. version 20; 

camera, device —» base. common. module = ( hw. module t * ) (module) ; 
camera, device —> base. common. close = camera, device, close; 


camera, device —> base. ops = camera, ops ; 


camera, ops — > set, preview. window = camera, set, preview. window; 
camera, ops — > set, callbacks = camera, set. callbacks; 

camera, ops —» enable msg type = camera, enable msg type; 
camera, ops — > disable msg type = camera, disable msg type; 
camera, ops -> msg type enabled = camera, msg, type. enabled; 
camera ops —> start, preview = camera, start, preview ; 

camera, ops — > stop. preview = camera, stop. preview ; 


camera, ops — > preview, enabled = camera, preview. enabled ; 





camera, ops — > store meta data in, buffers = camera, store meta, data in. buffers; 
camera, ops —> start, recording = camera, start, recording; 

camera, ops — > stop. recording = camera, stop. recording ; 

camera, ops — > recording enabled = camera, recording enabled ; 

camera, ops —> release recording frame = camera, release recording, frame; 
camera, ops — auto, focus = camera, auto, focus; 

camera, ops 一 > cancel, auto, focus = camera, cancel, auto, focus ; 

camera, ops —» take. picture = camera, take picture; 

camera, ops 一 > cancel, picture = camera, cancel picture ; 

camera ops —» set, parameters = camera, set, parameters ; 

camera ops — > get. parameters = camera, get, parameters ; 

camera, ops — > put, parameters = camera, put. parameters ; 

camera, ops — > send. command = camera, send. command; 

camera, ops 一 > release = camera, release; 


camera, ops -> dump = camera. dump; 


* device = &camera, device —> base. common; 
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/实际 适 配 的 实体 
camera, device —» cameraid = cameraid ; 
V41L2CameraHardware = new CameraHardware( ) ; 


| 


return rv; 


Android 框架 加 载 了 相应 的 HAL 模块 后 ， 就 会 通过 相应 的 camera_ops 来 操作 ， 而 这 
些 操作 都 是 适 配 操作 ， 实 际 上 是 调用 VAL2CameraHardware 中 的 实际 为 CameraHardware 


的 函数 。 











接 下 来 以 preview 为 例 ， 来 看 看 具体 的 适 配 操作 的 流程 : 


status_t CameraHardware ; : startPreview( ) 


| 


int width, height; 
int mHeapSize =0; 


int ret =0; 


if( ! mCamera) | 
delete mCamera; 
// 通 过 封装 V412 接口 的 camera 的 


mCamera = new V4L2Camera( ) ; 





























u 














// 不 同 版 本 内 核 可 能 产生 的 设备 文件 不 同 ,主要 是 历史 原因 ,需要 适 配 
if( version >=KERNEL_ VERSION(2,6,37) ) | 
if( mCamera -> Open( VIDEO_DEVICE_2) <0) 
return INVALID_OPERATION ; 
| else | 
if( mCamera -> Open( VIDEO. DEVICE 0) <0) 
return INVALID OPERATION ; 


Mutex ; : Autolock lock ( mPreviewLock ) ; 
if( mPreviewThread! =0) | 
return INVALID OPERATION ; 


// 获 得 参数 
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mParameters. getPreviewSize( &mPreviewWidth, &mPreviewHeight) ; 
ALOGD( " startPreview width; 96 d , height ; % d" , mPreviewWidth , mPreviewHeight) ; 
if( mPreviewWidth < 20 || mPreviewHeight < 20) | 

ALOGE( " Preview size is not valid, aborting. . Device can not open!!!" ) ; 


return INVALID. OPERATION; 


/进行 设置 
ret = mCamera -> Configure ( mPreviewWidth ,mPreviewHeight ,PIXEL_FORMAT,30) ; 
if(ret<0) | 

ALOGE("Fail to configure camera device" ) ; 

return INVALID OPERATION ; 


/进行 映射 

ret =mCamera -> BufferMap( ) ; 

if( ret) | 
ALOGE( " Camera Init fail; 96s" , strerror( errno) ) ; 
return UNKNOWN ERROR; 


/开始 采集 

ret = mCamera — > StartStreaming( ) ; 

if( ret) | 
ALOGE( " Camera StartStreaming fail; 96s" , strerror( errno) ) ; 
mCamera — > Uninit( ) ; 
mCamera — > Close( ) ; 


return UNKNOWN ERROR; 


/ * start preview thread * / 
// J& 8l] preview 线程 进入 循环 操作 
previewStopped = false ; 


mPreviewThread = new PreviewThread( this ) ; 


return NO ERROR ; 





而 在 真正 的 preview 线程 中 会 通过 如 下 操作 将 采集 的 frame 经 过 转换 进行 显示 : 














if(0 == mapper. lock( ( buffer handle t) * hndl2hndl, CAMHAL GRALLOC USAGE, bounds, &dst) ) 
| 
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// Get preview frame 
/获得 采集 帧 


tempbuf = mCamera — > GrabPreviewFrame( ) ; 


// 进 行 格式 转换 以 便 进行 显示 

convert Y UY VtoRGB565 ( ( unsigned char * ) tempbuf, ( unsigned char * ) dst, width, height) ; 
mapper. unlock ( ( buffer. handle t) * hndlI2hndl) ; 

// 加 入 到 显示 处 理 中 

mNativeWindow -> enqueue_buffer( mNativeWindow, (buffer_handle_t * ) hndD2hndl) ; 

// 释 放 采 集 帧 


mCamera — > ReleasePreviewFrame( ) ; 





视频 设备 的 实际 操作 都 是 通过 V4L2Camera 中 的 标准 V4L2 接口 进行 的 ， 例 如 配置 
接口 。 








int V4L2Camera: :Configure(int width ,int height ,int pixelformat ,int fps) 
| 
int ret =0; 


struct v4I2. streamparm parm; 


if( version >= KERNEL VERSION(2,6,37) ) 
| 
videoln -> width = IMG_WIDTH_VGA; 
videoIn -> height = IMG HEIGHT. VGA ; 
videoIn -> framesizeIn = ( (IMG. WIDTH, VGA * IMG HEIGHT VGA) <1); 
videoIn -> formatIn = DEF. PIX FMT; 


videoIn -> format. fmt. pix. width = IMG. WIDTH. VGA ; 
videoIn -> format. fmt. pix. height = IMG. HEIGHT VCA ; 
videoIn -> format. fmt. pix. pixelformat = DEF. PIX FMT; 





videoIn -> format. type = VAL2. BUF TYPE VIDEO CAPTURE; 


do 
| 
ret =ioctl( camHandle, VIDIOC_S_FMT, &videoIn -> format) ; 
if( ret <0) | 
ALOGE(" Open: VIDIOC_S_FMT Failed; 96s" , strerror( errno) ) ; 
break ; 
} 
| while(0) ; 
return ret; 
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可 见 就 是 通过 VIDIOC_S FMT 实现 具体 的 操作 。 

Android 的 适 配 在 使 用 流程 上 与 应 用 的 实例 是 相同 的 ， 只 是 在 操作 上 封装 成 不 同 的 接口 ， 
而 且 将 参数 与 数据 流 控制 分 离 ， 这 样 方 便 了 管理 ， 也 易于 与 其 他 模块 交互 。 
6.4.4 TI 芯片 视频 驱动 相关 实现 详解 


对 视频 驱动 的 具体 实现 ， 以 DM3730 ISP 驱动 的 设计 与 实现 为 例 进行 介绍 。 首 先 来 看 一 
下 ISP 硬件 框架 ， 如 图 6-18 所 示 。 
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从 图 6-18 可 见 ，ISP 模块 允许 从 多 个 通道 读 取 数 据 ， 可 以 从 CSI, CCP 或 者 内 存 ， 而 且 


硬件 模块 本 身 还 可 以 屏蔽 ,另外 其 中 内 骨 MMU 可 以 实现 帧 数据 使 用 物理 不 连续 的 内 存 空 
分 强大 ， 这 就 需要 驱动 软件 支持 这 些 特性 ， 能 够 容易 地 设置 不 同 的 数 


间 。 从 硬件 看 其 功能 
据 进 出 以 及 操作 方式 ， 从 而 更 好 地 使 用 便 件 功能 。 
对 这 种 需要 灵活 配置 的 设备 ，media controller 是 最 适合 的 ， 在 实际 的 驱动 设计 中 也 是 采 



































1. 整体 框架 及 应 用 层 接口 
用 了 该 方法 进行 驱动 的 架构 设计 。 驱 动 的 整体 框架 如 图 6-19 所 示 。 
Secondary sensor OMAP3 ISP CCP2 Primary sensor Lens controller Flash controller 
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AT ZTE (A ISP CCDC) 都 是 

















EAR 








从 图 6-19 中 可 见 ， 其 中 有 很 多 的 节点 
子 设 备 是 一 个 功能 模块 ， 实 现 具 体 的 功能 ， 而 单一 矩形 的 节点 (包含 /dev/video?) 是 video 








HH, 
点 的 抽象 以 及 管理 实体 。 细 节 如 下 : 


设备 文件 ， 这 些 设备 文件 是 数据 流 的 入口 或 者 
ISP 驱动 中 使 用 isp_video 作为 以 上 单一 矩形 节 


struct isp_video | 
// 视 频 驱 动 框架 的 应 用 层 管理 实体 


struct video_device video; 





//buffer 类 型 
enum v412 buf type type; 
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// 相 应 的 media pad 信息 ,用 于 初始 化 video 中 的 entity 信息 
struct media_pad pad; 


struct mutex mutex ; 


atomic_t active; 


// 连 接 到 整个 ISP 的 管理 实体 


struct isp_device * isp; 








// 需 要 的 buffer 空间 
unsigned int capture_mem; 


unsigned int alignment; 


/ * Entity video node streaming * / 
//streaming 的 状态 


unsigned int streaming :1 ; 


/ * Pipeline state * / 
// Xt 0 pipeline ,表示 具体 设备 所 在 的 数据 pipeline 


struct isp_pipeline pipe; 





struct mutex stream_lock; 


/ * Video buffers queue * / 
// 针 对 应 用 层 的 buffer queue 
struct isp_video_queue * queue; 


// 针 对 底层 驱动 的 buffer queue 


struct list_head dmaqueue; 








enum isp_video_dmaqueue_flags dmaqueue_flags ; 


const struct isp_video_operations * ops; 


l; 


SE A A EXEC Hh BR AS ARRS HEAT AE EH VE, HRS AL: 


int isp_video_init( struct isp_video * video, const char * name) 
const char * direction; 


int ret; 





// 根 据 类 型 设置 pad 信息 
switch (video —> type) | 
case V4L2_BUF_TYPE_VIDEO_CAPTURE : 
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direction = " output" ; 


video —> pad. flags = MEDIA_PAD_FLAG_INPUT; 


break ; 


case V4L2_BUF_TYPE_VIDEO_OUTPUT; 





direction = " input" ; 


video —> pad. flags = MEDIA_PAD_FLAG OUTPUT; 


break ; 


default : 
return — EINVAL; 


// 初 始 化 entity 以 便 进行 连接 


ret = media_entity_init( &video -> video. entity, 1, &video -> pad, 0) ; 


if( ret «0) 


return ret; 


mutex, init( &video —» mutex) ; 


atomic, set( &video —> active, 0) ; 


spin, lock, init( &video —> pipe. lock ) 


mutex, init( &video -> stream lock) ; 


/ * Initialize the video device. * / 


if( video -> ops == NULL) 


, 


video -> ops = &isp. video. dummy. ops; 


设备 文件 的 操作 接口 


video —> video. fops = &isp_video_fops; 


snprintf( video —» video. name, sizeof( video —> video. name) , 


"OMAP3 ISP 96s 96s" , name, 


// 帧 类 型 设备 设置 


direction) ; 


video —> video. vfl type = VFL_TYPE_GRABBER; 


video —> video. release = video_device_release_empty ; 


//ioctl 控制 接口 


video -> video. ioctl_ops = &isp_video_ioctl_ops; 


//pipeline 状态 是 stop 


video -> pipe. stream_state = [SP_PIPELINE_STREAM_STOPPED; 


// 标 记 驱 动 的 数据 以 便 驱 动 的 应 用 




















层 接口 使 用 ,这 是 








video_set_drvdata( &video —> video, video) ; 


Ier a J 
HE isp. video 
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return 0; 


这 里 只 有 初始 化 ， 而 实际 的 注册 由 isp_video_register 完成 ， 细 节 如 下 : 


int isp. video. register( struct isp_video * video, struct v412_device * vdev) 


| 


这 样 注册 了 实际 的 视频 设备 ， 相 应 应 用 层 的 操作 就 通过 注册 的 接口 进行 了 。 通 


int ret; 
video —> video. v412_dev = vdev; 


// 回 视频 框架 注册 接口 
ret = video_register_device( &video —» video, VFL_ TYPE GRABBER, -1); 
if(ret <0) 

printk( KERN. ERR "26s; could not register video device( 96 d) Wn" , 


— fune, ret); 





// 支 持 的 标准 
video —> video. tvnorms = VAI2, STD. NTSC | VAL2 STD PAL; 
video —> video. current. norm = VAI2. STD. NTSC; 


return ret ; 








子 来 看 看 具体 的 接口 是 如 何 实现 的 。 
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static int isp_video_try_format( struct file * file, void * fh, struct v4l2 format * format) 


| 


/人 /获得 驱动 对 应 的 管理 实体 

struct isp_video * video = video_drvdata( file) ; 
struct v412_subdev_format fmt; 

struct v412_subdev * subdev; 

u32 pad; 


int ret; 


if( format —» type! = video —> type) 
return — EINVAL; 


// 查 询 获 得 连接 的 子 设备 ,由 media controller 接口 实现 
subdev = isp_video_remote_subdev( video, &pad) ; 
if( subdev == NULL) 


过 一 个 例 


return — EINVAL; 


/将 像素 信息 转换 成 media bus 信息 


isp_video_pix_to_mbus( &format -> fmt. pix, &fmt. format) ; 


// MK. subdev 侧 获得 信息 
fmt. pad = pad; 
fmt. which = V4L2_SUBDEV_FORMAT_ACTIVE; 
ret = v412_subdev_call(subdev, pad, get fmt, NULL, &fmt) ; 
if( ret) 
return ret == — ENOIOCTLCMD ? -EINVAL : ret; 


// 转 换 回 pix 信息 


isp_video_mbus_to_pix( video, &fmt. format, &format —» fmt. pix) ; 





return 0; 


可 见 实际 的 操作 是 由 子 设备 完成 的 ， 子 设备 与 具体 功能 相关 。 

2. 子 设备 及 连接 管理 

ISP 驱动 中 每 个 功能 节点 都 是 一 个 subdev， 而 相应 的 连接 也 要 进行 管理 ， 这 些 都 要 由 具 
体 功能 模块 来 进行 ， 以 CCDC 为 例 看 看 是 如 何 实现 的 。 


static int isp_ccdc_init_entities( struct isp_ccde_device * cede) 
struct v412_subdev * sd = &ccdc -> subdev ; 
struct media, pad * pads = ccdc -> pads; 
struct media, entity * me = &sd —> entity; 


int ret ; 
cede —> input = CCDC. INPUT. NONE; 


// 初 始 化 子 设备 ,主要 是 将 操作 初始 化 ,包括 各 种 操作 
v4D. subdev. init(sd, &ccde_v412_ops) ; 
strlepy( sd -> name, " OMAP3 ISP CCDC", sizeof( sd -> name) ) ; 
// 驱 动 定义 的 组 号 
sd —>erp_id=1 ««16; / * group ID for isp subdevs */ 
人 设置 设备 私有 数据 
v4I2. set, subdevdata( sd, cede) ; 
// 设 置 有 事件 上 报 ,有 设备 文件 进行 控制 操作 
sd —> flags |= V4L2_SUBDEV_FL_HAS_EVENTS | 
V4L2 SUBDEV FL HAS DEVNODE; 
/事件 缓冲 数目 ,用 于 框架 为 应 用 层 缓 站 事件 


















































569 


sd —» nevents = OMAP3ISP_CCDC_NEVENTS; 


/控制 接口 初始 化 
v412_ctrl_handler_init(&ccdc -> ctrls, 1) ; 


sd —> ctrl_handler = &ccde —> ctrls; 








//pad 信息 初始 化 

pads[ CCDC_PAD_SINK J. flags = MEDIA_PAD_FLAG_INPUT; 

pads[ CCDC. PAD. SOURCE. VP]. flags = MEDIA. PAD. FLAG. OUTPUT; 
pads[ CCDC. PAD. SOURCE OF]. flags = MEDIA. PAD FLAG. OUTPUT; 


//media controller 操作 接口 设置 

me —> ops = &ccdc_media_ops; 

// 初 始 化 media entity 

ret = media_entity_init(me, CCDC_PADS_NUM, pads, 0); 
if(ret <0) 


return ret; 


cede, init, formats( sd, NULL) ; 








// 初 始 化 驱动 对 于 应 用 层 的 管理 实体 isp_video 
cede —> video, out. type = V4L2_BUF_TYPE_VIDEO_CAPTURE; 


cede —> video, out. ops = &ccdc_video_ops; 

















cede —> video, out. isp = to_isp_device( cede) ; 
cede —> video, out. capture mem = PAGE ALIGN(4096 * 4096) * 3; 


cede —> video, out. alignment 232; 


// 初 始 化 相应 信息 
ret = isp_video_init( &ccde -> video out, "CCDC" ) ; 
if( ret <0) 


return ret; 


/ * Connect the CCDC subdev to the video node. */ 

// 将 CCDC 的 子 设 备 与 应 用 层 设备 文件 连接 起 来 

ret = media_entity_create_link( &ccdc -> subdev. entity, CCDC_PAD_SOURCE_OF, 
&ccdc —> video. out. video. entity, 0, 0) ; 

if( ret <0) 


return ret ; 





return 0; 
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同样 有 注册 操作 


int isp_ccdc_register_entities( struct isp_ccde_device * cede, struct v4l2_device * vdev) 


| 
l 


int ret; 


/ * Register the subdev and video node. */ 

// 注 册 subdev 

ret = v4]2_device_register_subdev( vdev, &cede -> subdev) ; 
if(ret <0) 


goto error; 


// 注 册 了 驱动 的 应 用 层 管理 实体 isp_video 
ret = isp_video_register( &ccdc -> video out, vdev) ; 
if(ret <0) 


goto error; 
return 0; 


error: 
isp_ccdc_unregister_entities( cede) ; 


return ret; 


} 
这 样子 设备 以 及 连接 就 建立 起 来 了 。 下 面 来 看 看 连接 media controller 的 操作 : 


static int ccdc_link_setup(struct media, entity * entity, const struct media pad * local, 


const struct media pad * remote, u32 flags) 


struct v412_subdev * sd = media, entity to v412, subdev( entity) ; 
struct isp. ecde, device * cede = v412, get. subdevdata( sd) ; 


struct isp. device * isp = to. isp. device( ccdc ; 





/根据 各 种 输入 和 输出 的 情况 记录 输入 的 属性 
switch( local -> index | media_entity_type( remote -> entity) ) | 
case CCDC_PAD_SINK | MEDIA, ENTITY TYPE V4L2 SUBDEV: 
/ * Read from the sensor( parallel interface), CCP2, CSI2a or 
* CSc. 
*/ 
if( ! (flags & MEDIA. LINK FLAG, ENABLED) ) | 
cede -> input = CCDC. INPUT NONE ; 
break ; 
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if( cede —> input! = CCDC_INPUT_NONE) 
return — EBUSY; 


if( remote -> entity == &isp -> isp. ccp2. subdev. entity ) 
cede -> input = CCDC_INPUT_CCP2B; 

else if( remote —» entity == &isp -> isp. csi2a. subdev. entity ) 
ccdc —> input = CCDC_INPUT_CSI2A; 

else if( remote —> entity == &isp -> isp_csi2c. subdev. entity ) 
cede —> input = CCDC_INPUT_CSI2C; 


else 











ccdc —> input = CCDC_INPUT_PARALLEL; 
break ; 


case CCDC_PAD_SOURCE_VP | MEDIA_ENTITY_TYPE_V4L2_SUBDEV; 





/ * Write to preview engine, histogram and H3A. When none of 
* those links are active, the video port can be disabled. 
*/ 

if( flags & MEDIA. LINK FLAG. ENABLED) | 

if( cede —> output & ~ CCDC. OUTPUT. PREVIEW ) 
return — EBUSY; 
cede -> output |= CCDC. OUTPUT. PREVIEW ; 
| else | 
ccde —> output & = ~ CCDC. OUTPUT. PREVIEW ; 
| 
break ; 


case CCDC_PAD_SOURCE_OF | MEDIA, ENTITY TYPE DEVNODE: 

/ * Write to memory * / 
if( flags & MEDIA. LINK FLAG. ENABLED) | 

if( cede —> output & ~ CCDC. OUTPUT MEMORY) 

return — EBUSY; 

cede -> output | = CCDC_OUTPUT_MEMORY ; 
| else | 

ccdc —» output & = ~ CCDC. OUTPUT MEMORY; 
| 
break ; 


case CCDC_PAD_SOURCE_OF | MEDIA_ENTITY_TYPE_V4L2_SUBDEV: 
/ * Write to resizer * / 


if(flags & MEDIA_LINK_FLAG_ENABLED) | 
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| 


if( cede ->output & ~CCDC_OUTPUT_RESIZER ) 
return — EBUSY ; 
cede -> output |= CCDC_OUTPUT_RESIZER ; 
| else | 
ccdc —> output & = ~ CCDC. OUTPUT. RESIZER ; 
| 


break ; 
default ; 


return — EINVAL; 


return 0; 


可 见 连接 建立 只 是 进行 输入 和 输出 子 设备 节点 的 状态 记录 ， 实 际 操作 视频 流 streaming 
on 是 在 子 设备 的 s. stream 操作 中 调用 ccdc_configure 来 完成 的 ， 而 相应 的 ccdc_configure 则 是 


根据 cede, link. setup 时 的 属性 进行 相应 的 寄存 器 设置 。 这 样 就 可 以 完成 连接 框架 到 实际 设备 
操作 的 流程 。 








3. 视频 数据 流 
关于 视频 数据 流 ，ISP 驱动 框架 涉及 两 个 管理 实体 ， 其 一 是 isp_pipeline， 表 示 流 的 物理 
pipeline 路 径 。 细 节 如 下 : 


struct isp_pipeline | 


//media controller 中 的 pipeline, E media controller 实体 中 指示 其 所 在 的 pipeline 
struct media_pipeline pipe; 

spinlock_t lock; 

//pipeline 的 状态 由 枚 举 isp_pipeline_state 表示 

unsigned int state; 

//pipeline 中 的 stream 的 状态 

enum isp_pipeline_stream_state stream_state ; 

//pipeline 中 的 input 应 用 层 管理 实体 会 对 应 一 个 设备 文件 ,如 果 为 空 通常 是 
//camera sensor 输入 

struct isp_video * input; 

//pipeline 中 的 output 应 用 层 管理 实体 会 对 应 一 个 设备 文件 

struct isp_video * output; 

/7 时钟 相 关 的 设置 

unsigned long 13_ick; 

//pipeline 上 各 模块 的 最 大 时 钟 

unsigned int max_rate; 

// 采 集 的 帧 数 


atomic_t frame_number; 
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bool do, propagation; / * of frame number * / 
struct v412. fract max_timeperframe ; 


JE 














这 里 主要 是 各 个 设备 文件 所 在 的 数据 通道 连接 状况 及 其 状态 ， 这 ER 
Be 这 些 状态 信息 会 在 电源 管理 中 有 相应 的 切 能 ， 比如 条 统 从 低 项 村 状态 恢复 执行 时 ， 
恢复 数据 流传 送 ， 这 时 候 就 会 从 输入 端 进行 恢复 ， 需 要 保留 这 些 信息 。 相 应 的 属 a 
stream on 操作 中 执行 5 相关 代码 详细 内 容 如 下 : 














// 获 得 最 远 端的 设备 文件 节点 ,如 果 为 空 则 表示 是 camera sensor 


far end = isp_video_far_end( video); 




















// 根 据 当 前 设备 文件 节点 的 类 型 进行 pipeline 属性 设置 
if( video —> type == V4L2_BUF_TYPE_VIDEO_CAPTURE) | 

// 对 于 capture 设备 buffer 是 输出 到 内 存 中 

state = ISP_PIPELINE_STREAM_OUTPUT | ISP_PIPELINE_IDLE_OUTPUT; 


























pipe —> input = far_end; 


pipe —> output = video; 


} else | 
if(far end == NULL) | 
ret = — EPIPE; 
goto error; 


state = ISP. PIPELINE STREAM, INPUT | ISP_PIPELINE_IDLE_INPUT; 
pipe —> input = video; 
pipe —> output = far_end; 
| 
/ / V Ei £X T TE, 主要 是 会 设置 总 线 时 钟 
omap_pm_set_min_bus_tput( video -> isp -> dev, OCP. INITIATOR, AGENT, 740000) ; 
pipe —> 13. ick = clk_get_rate( video —> isp —> clock[ ISP_CLK_L3_ICK ] ) ; 



































/ * Validate the pipeline and update its state. */ 
// 验 证 pipeline 

ret = isp_video_validate_pipeline( pipe) ; 

if(ret <0) 


goto error; 





// 设 置 pipeline 状态 




















spin_lock_irqsave( &pipe -> lock, flags) ; 
pipe —> state & = ~ ISP. PIPELINE STREAM ; 


pipe —> state | = state; 
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spin unlock irqrestore( &pipe —> lock, flags) ; 


if( video —> type == VAL2. BUF TYPE VIDEO OUTPUT) 


pipe -> max, timeperframe = vfh -> timeperframe; 





// 对 于 buffer queue 的 操作 

video -> queue = &vfh -> queue; 

// 初 始 化 驱动 的 队列 

INIT_LIST_HEAD( &video -> dmaqueue) ; 


atomic, set( &pipe —» frame number, - 1) ; 


// buffer queue 启动 
ret = isp. video. queue streamon( &vfh -> queue) ; 
if( ret <0) 


goto error; 











// 如 果 是 从 camera sensor 开始 ,设置 硬件 进入 连续 模式 
if( pipe -> input == NULL) | 
ret = isp. pipeline, set, stream( pipe, 


ISP. PIPELINE STREAM, CONTINUOUS) ; 














if( ret «0) 
goto error; 
spin. lock, irqsave( &video -> queue —> irglock, flags) ; 
// 此 种 情况 应 该 驱动 buffer 队列 中 有 buffer, WRA buffer 则 是 underrun 异常 
if( list_empty( &video -> dmaqueue) ) 
video -> dmaqueue_flags | = ISP_VIDEO_DMAQUEUE_UNDERRUN ; 





spin, unlock, irqrestore( &video -> queue —> irqlock, flags) ; 


通过 分 析 可 知 ， 很 多 系统 的 设置 就 是 通过 pipeline 的 状态 进行 的 ， 其 中 包括 stream 的 操 
作 ， 对 stream 的 操作 还 要 通过 pipeline 的 操作 完成 ， 相 应 的 接口 是 isp_pipeline_enable， 详 细 
内 容 如 下 : 

















static int isp_pipeline_enable( struct isp pipeline * pipe, 


enum isp. pipeline stream. state mode ) 


struct isp. device * isp = pipe -> output —> isp; 
struct media entity * entity; 

struct media pad * pad; 

struct v412_subdev * subdev; 

unsigned long flags; 


int ret 20; 
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spin lock irqsave( &pipe -> lock, flags) ; 
pipe -> state & = ~ (ISP_PIPELINE_IDLE_INPUT | ISP_PIPELINE_IDLE_OUTPUT) ; 
spin_unlock_irgrestore( &pipe —» lock, flags) ; 


pipe -> do_propagation = false; 


// 先 找到 输出 的 实体 ,然后 从 输出 实体 向 输入 实体 进行 遍历 
entity = &pipe -> output —> video. entity ; 
while(1) | 
// 找 到 相应 的 输入 pad ,在 设置 时 ,如 果 有 输入 pad ,就 使 用 0 pad 
// 如 果 0 号 pad 不 是 输入 pad, 则 已 经 对 输入 端 进行 操作 ,表示 遍历 结 
pad = &entity -> pads[ 0] ; 
if( ! (pad -> flags & MEDIA_PAD_FLAG_INPUT) ) 
break ; 














// 问 输入 端 推进 

pad = media_entity_remote_source( pad) ; 

// 保 证 中 间 是 subdev 

if( pad == NULL || media_entity_type( pad -> entity) ! = 
MEDIA_ENTITY_TYPE_V4L2_SUBDEV ) 








break ; 


// 通 过 entity 获得 subdev 实体 
entity = pad —> entity; 


subdev = media_entity_to_v412_subdev( entity) ; 


// 对 子 设 备 根据 mode 进行 stream 操作 
ret = v4I2, subdev. call(subdev, video, s stream, mode) ; 
if( ret «0 && ret! = - ENOIOCTLCMD) 

break ; 


if( subdev == &isp -> isp. cede. subdev) | 
// 如 果 是 CCDC 需要 对 3A 模块 进行 设置 
v412_subdev_call( &isp -> isp_aewb. subdev, video, 





























s_stream, mode) ; 

v412_subdev_call( &isp -> isp_af. subdev, video, 
s_stream, mode) ; 

v412_subdev_call( &isp -> isp. hist. subdev, video, 
s_stream, mode) ; 


pipe —> do_propagation = true; 
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if( pipe -> do propagation && mode == ISP PIPELINE STREAM. SINGLESHOT) 


atomie, inc( &pipe -> frame, number) ; 


return ret ; 


MPA UL, pipeline 就 是 遍历 数据 终点 到 起 点 的 所 有 子 设备 ， 并 进行 相应 的 stream 操作 
来 保证 pipeline 中 所 有 的 模块 正确 工作 。 

另 一 个 重要 的 管理 实体 是 isp_video_queue， 这 里 没有 使 用 videobuf2 架构 是 由 于 在 相应 
驱动 开发 时 内 核 还 没有 相关 的 架构 ， 但 是 相应 的 queue 可 以 看 到 videobuf2 的 影子 。 先 来 看 
看 的 isp_video_queue 细节 ; 














struct isp_video_queue | 
//buffer 的 类 型 
enum v4l2_buf_type type; 
// 驱 动 提供 对 应 的 操作 接口 


const struct isp_video_queue_operations * ops; 














struct device * dev; 


unsigned int bufsize ; 


unsigned int count; 


// 具 体 的 buffer 管理 实体 指针 
struct isp_video_buffer * buffers| ISP_VIDEO_MAX_BUFFERS ] ; 


struct mutex lock; 























spinlock_t irglock ; 
unsigned int streaming :1 ; 
// 实 际 的 buffer 队列 


struct list_head queue; 


bs 











这 里 的 queue 同样 是 应 用 层 的 接口 队列 ， 在 isp_video 中 可 以 看 到 它 的 指针 ， 而 实际 驱 
动 操作 的 buffer 形成 以 dmaqueue 为 列表 头 的 列表 。 实 际 驱 动 提供 的 接口 如 下 : 





static const struct isp_video_queue_operations isp_video_queue_ops = | 
. queue. prepare = &isp. video, queue. prepare, 
. buffer. prepare = &isp. video buffer prepare, 


. buffer queue = &isp. video buffer queue, 


577 


. buffer_cleanup = &isp_video_buffer_cleanup , 


l; 


其 中 ，isp_video_buffer_queue 的 工作 就 是 将 isp_video_queue 中 的 buffer 加 入 到 驱动 中 进 
行 操作 ， 操 作 结 束 后 ， 会 在 中 断 中 根据 具体 的 情况 通过 isp_video_buffer_next 将 buffer 归还 给 
isp_video_queue， 以 便 完 成 应 用 的 相关 操作 。 层 次 关系 与 videobuf2 是 一 致 的 ， 只 是 videobuf2 
细 化 了 相关 的 接口 ， 使 用 范围 也 更 广 。 

这 样 就 完成 了 数据 流 相关 的 操作 。 

4. camera sensor 

还 剩 下 一 部 分 就 是 camera sensor 的 驱动 ，camera sensor 实际 上 是 通过 了 了 C 总 线 进行 连接 
的 外 部 设备 ， s 由 于 与 主 处 理 需 的 ISP 绑 定 比较 紧密 ， 也 为 了 系统 移植 的 方便 ， 将 其 做 成 
subdev 更 合适 ， 下 面 以 mt9t111 sensor 驱动 进行 说 明 。 

ete. 
































static int __init mt9t111_init( void) 
| 
return i2c_add_driver( &mt9t111_i2c_driver) ; 


| 





对 要 相应 的 驱动 ， 对 应 的 匹配 是 通过 ID table 来 完成 的 ， 后 续 介 绍 总 线 时 
会 详细 介绍 。 接 下 来 就 是 具体 的 probe: 











static int mt9t111_probe( struct i2c_client * client, const struct i2c_device_id * id) 


| 
struct mt9t111 * miOt111; 


int ret ; 


/ * Check if the adapter supports the needed features * / 
// 检 查 总 线 控制 器 是 否 文 持 相应 功能 
if( ! i2c check functionality ( client -> adapter, I2C_FUNC_SMBUS_BYTE_DATA) ) | 
vAl err( client, " mt9t111; DPC Adapter doesn t support" V 
" 2C FUNC SMBUS WORD") ; 
return — EIO; 





if( ! client -> dev. platform. data) | 
v4l_err( client, "No platform data! ! Wn"); 
return - ENODEV ; 


/分 配 管理 实体 
mi9t111 = kzalloc( sizeof( * mi91111) , GFP. KERNEL) ; 
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if( mt9t111 == NULL) 
v4l_err(client, "Could not able to alocate memory!! \n") ; 


return - ENOMEM ; 





/设置 设备 默认 格式 等 信息 


mi9t111 -> pdata = client —> dev. platform, data; 








mi9t111 —> rect. left =0; 
mi9t111 —> rect. top 20; 
mi9t111 —> rect. width 2640; 
mi9t111 —> rect. height = 480; 


mi9t111 -> format. code = VAL2 MBUS FMT UYVYS 2X8; 
mi9t111 —> format. width 2640; 

mi9t111 —> format. height = 480; 

mt9t111 —» format. field = VAL2. FIELD NONE ; 

mi9t111 —> format. colorspace = VAL2. COLORSPACE JPEG ; 





// 注 册子 设备 有 设备 文件 ,没有 event 处 理 
v4D. i2e subdev init( &mt9t111 -> subdev, client, &mt9t111 ops); 
mi9t111 -> subdev. flags | = V4L2_SUBDEV_FL_HAS_DEVNODE; 








// 只 有 输出 的 pad, 只 能 作为 数据 源 
mi9t111 -> pad. flags = MEDIA. PAD FLAG. OUTPUT; 
/创建 连接 实体 
ret = media entity init( &mt9t111 -> subdev. entity, 1, &mt9t111 -> pad, 0); 
if( ret «0) 
kfree( mt9t111) ; 





return ret ; 


这 样 连接 实体 与 子 设备 的 操作 实体 都 建立 了 ， 在 应 用 中 可 以 通过 如 下 的 代码 将 sensor 与 
ISP 进行 连接 . 


link. flags |= MEDIA_LINK_FLAG_ENABLED; 
link. source. entity = medialn -> mt9t111; 


link. source. index =0; 


link. source. flags = MEDIA, PAD FLAG. OUTPUT; 


link. sink. entity = medialn —» cede; 
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link. sink. index =0; 
link. sink. flags = MEDIA_PAD_FLAG_INPUT; 


ret = ioctl (medialn —» media, fd, MEDIA_IOC_SETUP_LINK, &link) ; 


由 于 后 续 操 作 的 sensor 在 pipeline 的 连接 中 ， 就 可 以 通过 ISP pipeline 的 操作 来 遍历 并 调 
用 相应 子 设备 的 接口 ， 对 于 sensor 子 设备 的 接口 这 里 就 不 进行 详 述 ， 主 要 的 操作 还 是 通过 
PC 总 线 来 完成 的 。 

而 设备 信息 的 注册 则 是 通过 isp_subdev_i2c_board_info 传人 到 ISP 驱动 中 ， 并 在 初始 化 
时 ， 通 过 isp_register_subdev_group 来 完成 。 具 体 如 下 : 



































static struct v4l2_subdev * isp_register_subdev_group( struct isp_device * isp, 


struct isp_subdev_i2c_board_info * board info) 





struct v412_subdev * sensor = NULL; 


unsigned int first; 


if( board, info -> board, info == NULL) 
return NULL; 


/遍历 所 有 的 信息 
for( first = 1; board, info ->board_info; ++ board_info, first =0) | 
struct v412_subdev * subdev; 


struct i2c_adapter * adapter; 


// 检 查 Y C 适 配 需 
adapter = i2c_get_adapter( board info -> i2c_adapter_id) ; 
if( adapter == NULL) | 
printk( KERN, ERR "26s; Unable to get I2C adapter 96 d for " 


"device 96 s\n" fune , 


board info -> i2c adapter id, 
board info -> board, info —» type) ; 


continue ; 














rr 





// 使 用 v4l2 提供 的 PC 辅助 接口 注册 相应 的 视频 子 设备 ,函数 内 部 会 注 
/TC 设备. 
subdev = v412_i2c_new_subdev_board( &isp -> v412_dev, adapter, 
board info -> board. info, NULL, 1); 
if( subdev 22 NULL) | 
printk( KERN, ERR " 96s; Unable to register subdev 96s Wn" , 
. fune. , board, info -> board info —» type) ; 
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| 


continue ; 


} 
if( first) 
sensor = subdev; 


| 


return sensor ; 

















这 里 操作 的 主要 目的 就 是 注册 v412 的 子 设备 和 了 C 的 设备 ， 通 过 工 C 总 线 适 配 将 视频 子 
设备 与 了 C 的 Camera Sensor 关联 起 来 ， 从 而 实现 完整 的 驱动 和 设备 连接 。 


6.4.5 视频 驱动 电源 管理 相关 说 





关于 视频 驱动 的 电源 管理 部 分 ， 
耗 的 电源 管理 ， 通 过 omap3isp_pm_ops 接口 提供 











static const struct dev_pm_ops omap3isp_pm_ops = | 


E 


. prepare = isp. pm, prepare, 
. suspend = isp. pm, suspend, 
.resume = isp pm resume, 


. complete = isp. pm. complete , 


接 下 来 看 看 具体 的 实现 细节 


static int isp pm, prepare( struct device * dev) 


| 


struct isp_device * isp = dev_get_drvdata( dev) ; 


int reset; 


if( isp —>ref_count ==0) 

return 0; 
//suspend 所 有 的 模块 
reset = isp suspend  modules( isp) ; 
/关闭 中 断 
isp_disable_interrupts(isp ) ; 
// 包 含 上 下 文 
isp_save_ctx(isp) ; 
if( reset) 


isp_reset(isp) ; 


return 0; 








DM 3730 的 ISP 驱动 提供 
kt 相关 功能 ， 细 节 如 下 : 





了 该 部 分 的 功能 ， 主 要 为 低 功 
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static int isp pm, suspend( struct device * dev) 


| 


struct isp_device * isp = dev_get_drvdata( dev) ; 


WARN. ON( mutex, is locked( &isp -> isp_mutex) ) ; 
// 如 果 在 使 用 时 suspend 关闭 时 钟 


if( isp —> ref count) 





isp. disable clocks( isp) ; 


return 0; 


static int isp pm, resume( struct device * dev) 


| 


struct isp_device * isp = dev_get_drvdata( dev) ; 


if( isp -> ref count ==0) 
return 0; 
// 恢 复 suspend 时 关 掉 的 时 钟 


return isp_enable_clocks( isp) ; 


static void isp_pm_complete(struct device * dev) 


| 


struct isp_device * isp = dev_get_drvdata( dev) ; 


if( isp — > ref count ==0) 


return ; 


IINE EP X 

isp. restore cix( isp) ; 

A/ 打开 中 断 
isp_enable_interrupts(isp ) ; 
/恢复 所 有 的 模块 


isp. resume, modules( isp) ; 


在 所 有 的 modules 的 suspend 和 resume 操作 过 程 中 ， 会 根据 pipeline 的 状态 进行 pipeline 
相关 操作 ， 通 过 以 下 函数 实现 ， 具 体 细节 如 下 : 





static void isp_pipeline_resume( struct isp_pipeline * pipe) 


| 
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// 检 查 模式 是 连续 模式 还 是 单 帧 模式 
int singleshot = pipe — > stream, state == ISP PIPELINE STREAM, SINGLESHOT ; 


// 先 恢复 输出 和 输入 模块 的 模式 
isp_video_resume( pipe -> output, | singleshot) ; 
if( singleshot ) 

isp_video_resume( pipe -> input, 0) ; 
// 恢 复 pipeline 的 状态 


isp. pipeline enable( pipe, pipe —» stream, state) ; 


static void isp. pipeline suspend( struct isp. pipeline * pipe) 


| 
// disable pipeline , 这样 stream 就 停止 了 
isp_pipeline_disable( pipe) ; 


模块 的 动态 电源 管理 与 streaming 的 状态 紧密 结合 ， 在 子 设 备 的 操作 中 实现 。 以 CCDC 
为 例 ，ccdc_set_stream 完成 了 相关 的 功能 。 





static int ccdc_set_stream( struct v412_subdev * sd, int enable) 
| 
struct isp_ccde_device * cede = v412, get. subdevdata( sd) ; 
struct isp. device * isp = to. isp. device( cede) ; 


int ret 20; 


if( cede —> state == ISP. PIPELINE STREAM, STOPPED) | 
if( enable == ISP. PIPELINE STREAM, STOPPED) 
return 0; 
// 当 前 CCDC 的 状态 是 关闭 , 则 需要 先 恢复 模块 再 进行 设置 
isp_subclk_enable( isp, OMAP3_ISP_SUBCLK_CCDC) ; 
isp reg set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CFG, 
ISPCCDC_CFG_VDLC) ; 








cede, configure( cede) ; 


ispeede, config vp( cede) ; 
ispecde, enable vp( cede, 0) ; 
cede —> error 2 0; 


ispcede, print, status( cede ) ; 
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switch( enable) | 
case ISP. PIPELINE STREAM, CONTINUOUS: 


if( cede -> output & CCDC. OUTPUT MEMORY) 
isp. sbl, enable(isp, OMAP3 ISP SBL CCDC WRITE); 


if( cede -> underrun || ! (cede -> output & CCDC. OUTPUT MEMORY ) ) 


ispeede, enable( cede) ; 


cede -> underrun 20; 


break ; 


case ISP. PIPELINE STREAM. SINGLESHOT: 


if( cede -> output & CCDC. OUTPUT MEMORY && 
cede —> state! = ISP PIPELINE STREAM. SINGLESHOT) 
isp. sbl, enable(isp, OMAP3 ISP SBL CCDC WRITE); 


ispeede, enable( cede) ; 


break ; 


case ISP. PIPELINE STREAM STOPPED: 


// 需 要 关闭 stream 则 关闭 其 中 的 模块 

ret = ispecde, disable( cede ) ; 

if( cede -> output & CCDC, OUTPUT MEMORY ) 
isp_sbl_disable( isp, OMAP3 ISP SBL CCDC WRITE) ; 

isp_subclk_disable( isp, OMAP3 ISP SUBCLK, CCDC) ; 

cede -> underrun =0; 


break ; 





cede —> state = enable; 


return ret; 


从 中 可 见 ， 子 模块 会 根据 streaming 的 状态 进行 相应 的 电源 管理 操作 ， 这 样 低 功 耗 与 动 





态 电 源 管理 的 功能 就 完整 了 。 


6.5 小 结 


本 章 主 要 介绍 各 种 功能 型 设备 驱动 ， 各 种 驱动 会 根据 设备 的 数据 特点 进行 设计 ， 并 尽 





为 应 用 层 提供 








t 良 好 的 界面 ,方便 用 户 应 用 程序 的 开发 。 


=! 
H 


四 | 





功能 性 驱动 各 具 特 色 ， 其 中 框架 设计 也 包含 了 很 多 设计 思想 。 这 里 主要 以 层次 的 方式 分 
析 ， 将 整体 的 框架 从 针对 应 用 的 上 层 到 驱动 设备 操作 的 下 层 进行 完整 的 分 析 ， 当 从 上 至 下 打 
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通 时 ， 整 个 框架 就 清晰 地 展现 了 。 


BTE ”设备 驱动 忆 总 线 型 驱动 
7.1 内 部 集成 电路 总 线 (PC) 


7.1.1 PC 总 线 驱 动 需求 


PC (Inter - Integrated Circuit) 总 线 是 一 种 由 Philips 公司 开发 的 两 线 式 串 行 总 线 (分 别 
是 时 钟 信 号 SCL 和 数据 信号 SDA) 。 如 果 带 有 高 速 扩展 ， 则 最 高 可 到 3. 4 MHz。 其 具有 简单 
高 效 ， 总 线 占用 空间 小 ， 使 用 芯片 引 脚 少 ， 互 连 成 本 低 ， 可 以 进行 多 设备 互 连 等 优点 ， 被 广 
泛 应 用 于 处 理 器 与 外 围 设备 的 连接 。 

由 于 传感器 技术 的 大 力 发 展 ， 且 不 需要 大 量 的 数据 交换 ， 所 以 下 C 总 线 已 被 广泛 用 于 处 
理 器 连接 各 种 传感器 。 可 以 说 下 C 已 经 成 为 能 入 式 设备 不 可 或 缺 的 总 线形 式 。 

从 形式 上 看 TC 是 主 / 从 形式 总 线 ， 在 任何 时 间 点 上 只 能 有 一 个 主 控 。 般 入 式 处 理 器 通 
常 作为 PC 总 线 的 主 设备 ， 而 传感器 等 外 围 设 备 是 总 线 上 的 从 设备 。 从 设备 通常 有 固化 的 地 
址 ， 主 设备 通过 地 址 与 从 设备 通信 。 

PC 总 线 连接 的 基本 形式 如 图 7-1 所 示 。 图 7-1 引 自 《DM 3730 芯片 手册 》 中 第 2777 


Pullup resistors (Rp) 
Device *1.8V = *3.0 V 
| bos FC-1.8 V F'C-3.0 V 


compatible || compatible compatible 
device 













































k= == ss 


Al7-1 PC 总 线 连接 基本 形式 框图 





从 图 7-1 可 见 ， 处 理 器 中 可 以 有 多 个 PC 总 线 控制 器 ， 每 个 总 线 控制 器 形成 一 个 单独 的 
PC 总 线 ， 一 条 工 C 总 线 允 许 连接 多 个 设备 ， 而 且 设备 允许 使 用 不 同 的 接口 电压 ， 这 些 不 同 
接口 电压 的 设备 分 布 要 合理 。 如 芯片 的 I0 接口 电压 是 1.8V， 所 以 1.8V 的 设备 要 接近 芯 
片 ， 而 高 电压 3. 0V 接口 的 设备 则 通过 level shift 实现 升 夺 后 进行 连接 。 

总 线 可 以 连接 各 种 设备 ， 在 物理 设备 上 包含 总 线 控制 器 以 及 总 线 设 备 。 男 外 系统 的 硬件 
连接 需要 具有 灵活 性 ， 不 同 的 总 线 控制 器 可 以 连接 不 同 的 总 线 设备 ， 也 就 是 说 总 线 控制 器 与 
总 线 设备 要 独立 ， 不 能 够 彼此 相关 。 在 软件 方面 也 需要 具有 高 度 的 灵活 性 ， 设 备 信 息 要 与 驱 
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动 无 关 ， 总 线 控制 器 的 操作 方法 要 与 属性 无 关 ， 还 要 在 软件 层面 满足 总 线 控制 器 与 总 线 设 备 
无 关 。 

另外 从 设备 的 角度 来 看 ，PC 总 线 设备 有 具体 的 功能 ， 而 总 线 是 实现 功能 的 媒介 ， 通 过 
总 线 传输 命令 、 状 态 信 息 等 。 这 就 需要 总 线 系统 提供 信息 交互 的 接口 及 规范 ， 即 总 线 数据 传 
输 的 信号 规范 。EC 总 线 数据 传输 信号 规范 如 图 7-2 所 示 。 图 7-2 引 自 《DM 3730 芯片 手 
册 》 中 第 2778 页 框图 。 
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图 7-2 PC 总 线 数据 传输 信号 规范 








从 图 7-2 可 见 ， 具 体 传输 是 由 Start 和 Stop 标记 的 ， 并 且 每 传送 一 个 字 长 都 需要 有 ACK 
标记 。 通 常 传输 信号 的 正确 性 是 由 物理 的 控制 器 来 保证 的 ， 也 可 以 通过 GPIO 进行 模拟 ， 但 
是 需要 软件 进行 配合 。 

总 体 上 来 说 ， 系 统 对 工 C 总 线 驱 动 的 需求 就 是 要 能 实现 总 线 的 各 种 功能 ， 并 且 满 足以 上 
的 各 种 无 关 性 需求 。 


7.1.2 PC 总 线 驱 动 框架 解析 
1. 总 线 相关 以 及 核心 框架 











在 介绍 设备 模型 的 时 候 ， 已 经 介绍 了 设备 模型 中 的 总 线 抽 象 管理 ， 通 常 总 线 都 有 自动 
probe 功能 ， 即 可 以 在 向 设备 模型 注册 设备 或 者 驱动 的 时 候 ， 进 行 绑 定 操作 ， 由 具体 总 线 实 





例 化 相关 操作 。 了 解 总 线 相 关 操 作对 于 了 解 整个 总 线 框架 非常 有 帮助 。 

在 介绍 系统 初始 化 的 时 候 ，, 已 经 看 到 整个 了 C 的 初始 化 函数 Pe_init 定义 为 postcore_init- 
call, ŽRE PC 设备 或 者 驱动 注册 之 前 进行 注册 ， 从 而 保证 总 线 的 功能 。 而 初始 化 中 包 
含 如 下 语句 : 








retval = bus_register( &i2c_bus_type) ; 


这 里 注册 了 总 线 类 型 HP bus_register 会 设置 总 线 自 动 probe 功能 。 而 i2e bus type 可 
以 作为 了 解 整个 总 线 框架 的 和 人口， 详细 定义 如 下 : 





struct bus_type i2c_bus_type = | 


. name noc 
. match -i2e device match, 
. probe = 2c, device, probe, 
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N 


这 里 





. remove = i2c_device_remove , 
. shutdown -i2e device, shutdown, 


.pm = &i2c device pm ops, 


重点 的 接口 是 match 以 及 匹配 之 后 的 probe。 下 面 详细 分 析 这 两 个 接口 : 





static int i2c_device_match( struct device * dev, struct device driver * drv) 


| 


// 检 查 是 否 是 总 线 设备 


struct i2c_client * client = i2c_verify_client(dev) ; 





struct i2c_driver * driver; 
// 非 总 线 设备 直接 返 
if( ! client) 





到 


return 0; 


driver = to_i2c_driver( drv) ; 
/ * match on an id table if there is one * / 
// 匹 配 驱 动 的 ID 表 , 表 中 声明 文 持 的 设备 ,具体 的 匹配 方法 是 比较 字符 串 
if( driver -> id. table) 
return i2c_match_id( driver ->id_table，client) ! = NULL; 
































return 0; 


static int i2c_device_probe( struct device * dev) 


| 


// 检 查 是 否 是 总 线 设备 


struct i2c_client * client = i2c_verify_client(dev) ; 





struct i2c_driver * driver; 
int status; 

// 非 总 线 设备 则 直接 返回 

if( | client) 





return 0; 


driver = to_i2c_driver( dev -> driver) ; 

if( | driver —» probe || ! driver -> id. table) 
return - ENODEV ; 

// Tg V C 总 线 层 面 将 设备 与 对 应 的 驱动 绑 定 

client -> driver = driver; 

// WRI VC 设备 可 以 唤醒 系统 则 进行 标记 

if( | device_can_wakeup( &client -> dev) ) 
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device_init_wakeup( &client -> dev, 
client —> flags & I2C_CLIENT_WAKE) ; 
dev. dbg( dev, "probe\n" ) ; 


// 进 行 总 线 设 备 驱 动 的 探测 初始 化 工作 
status = driver —> probe( client, i2c_match_id( driver -> id. table, client) ) ; 
if( status ) | 
client -> driver = NULL; 
i2e set, clientdata( client, NULL) ; 
| 


return status ; 





从 分 析 中 可 见 ， 除 了 基本 的 操作 之 外 ， 两 个 接口 函数 都 通过 i2c_verify_client 进行 了 设 
备 的 验证 。 下 面 来 看 看 具体 的 内 容 。 





struct i2c_client * i2c_verify_client( struct device * dev) 


return( dev —> type == &i2c_client_type) 
? to_i2c_client(dev) : NULL; 


这 里 dev -> type 可 以 是 一 个 特殊 的 设备 类 型 De_client_type。 在 设备 模型 中 已 经 介 
绍 了 ，device 中 的 type 属性 在 功能 类 型 和 总 线 类 型 等 大 的 类 型 中 对 设备 进行 细 分 ， 并 进 
行 相应 操作 ， 这 里 就 是 实际 应 用 。 

进行 type 的 划分 说 明 不 止 一 种 设备 ， 下 面 来 看 看 工 C 总 线 的 不 同 设备 类 型 














struct device_type i2c_client_type; 


struct device_type i2c_adapter_type; 


其 中 有 两 种 类 型 的 设备 ， 分 别 是 i2c_client 类 型 和 i2c_adapter 类 型 。 进 行 这 样 的 分 类 是 
由 于 从 抽象 的 角度 考虑 ， 总 线 控制 器 也 是 设备 ， 而 作为 总 线 的 控制 接口 ， 其 物理 上 代表 的 是 
总 线 ， 而 不 是 总 线 上 连接 的 设备 ， 所 以 在 类 型 上 加 以 区 分 。 而 在 进行 总 线 级 别 的 匹配 时 ， 需 
要 进行 匹配 的 是 总 线 上 连接 的 设备 和 其 相应 的 驱动 ， 这 就 要 求 确 保 只 有 总 线 设备 进行 匹配 操 
作 ， 所 以 才 有 之 前 进行 检查 的 代码 。 

PC 总 线 框架 主要 就 是 对 这 两 类 设备 及 操作 进行 管理 ， 整 体 的 框架 如 图 7-3 所 示 。 

由 图 7-3 可 见 ，FC 核心 管理 的 实体 就 是 i2c_client、i2c_adapter 与 总 线 设备 相关 的 驱 
动 2c_driver。 为 了 管理 这 些 实体 ， 提 供 了 接口 函数 ， 后面 在 相关 部 分 会 对 其 进行 介绍 。 
另外 除了 以 上 的 两 类 设备 之 外 ， 系 统 还 提供 了 针对 应 用 层 的 操作 接口 管理 实体 i2e. dev, 
下 面 来 看 看 细节 : 
566 


















































user space device file 


Other Framwork 


ee 


adapter specific 
code 


hardware 
adapter hardware 
es | 


图 7-3 PC 总 线 内 核 框 架 





struct i2c_dev | 
struct list_head list; 
struct i2c_adapter * adap; 


struct device * dev; 


, 








其 中 提供 了 12e adapter 的 指针 ， 这 是 由 于 对 应 用 层 开 放 的 设备 文件 主要 提供 工 C 应 用 层 
驱动 的 功能 ， 作 为 驱动 主要 是 对 总 线 设备 的 操作 ， 通 过 总 线 控制 器 进行 总 线 操作 ， 所 以 这 里 
只 要 提供 相应 的 总 线 控制 器 即 可 ， 而 具体 与 哪个 了 C 从 设备 交互 及 相关 的 地 址 等 信息 都 是 通 
过 ioctl 命令 设置 的 。 这 样 对 下 层 的 操作 都 是 相同 的 ， 只 是 在 应 用 层 接 口 部 分 实现 i2c_client 
作为 操作 的 接口 即 可 。 下 面 来 看 看 了 TC 设备 文件 操作 接口 2cdev_fops 中 的 open RÆ: 
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static int i2cdev_open( struct inode * inode, struct file * file) 
| 
// 获 得 子 设备 号 
unsigned int minor = iminor( inode ; 
struct i2c_client * client; 
struct i2c_adapter * adap; 
struct i2c_dev * i2c_dev; 
// 获 得 管理 实体 ,对 应 于 设备 文件 
i2c_dev = i2c_dev_get_by_minor( minor) ; 
if( | i2e dev) 
return - ENODEV ; 
// 获 得 总 线 控制 器 实体 
adap = i2c_get_adapter( i2c_dev —> adap -> nr) ; 
if( ! adap) 
return - ENODEV ; 
// 这 里 创建 的 记 c_client 只 是 个 桩 ,并 不 会 注册 到 了 C 核心 中 ,后 面 可 以 通过 
//ioctl 命令 设置 slave 地 址 ,这样 只 作为 文件 操作 接口 保存 必要 的 信息 
client = kzalloc( sizeof( * client), GFP_KERNEL) ; 
if( ! client) | 


















































i2c put. adapter( adap) ; 
return - ENOMEM ; 


} 
snprintf( client -> name, I2C NAME SIZE, "i2c — dev 96d" , adap -» nr) ; 


client -> driver = &i2cdev. driver; 


// ORE E til tit 
client —> adapter = adap; 
// 与 文件 相关 联 


file -> private_data = client; 





return 0; 


| 
从 代码 中 可 见 ， 设 置 了 一 个 特殊 的 driver 即 i2cdev_driver， 下 面 来 查看 一 下 细节 . 





static struct i2c_driver i2cdev_driver = | 


. driver = | 
. name =" dev_driver" , 
1, 
. attach_adapter = i2cdev. attach. adapter, 
. detach, adapter = i2cdev. detach, adapter, 


l; 
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这 里 只 有 attach_adapter 和 detach_adapter 两 个 操作 接口 ， 这 两 个 接口 是 系统 用 于 处 理 新 
的 总 线 控制 器 加 入 或 者 退出 系统 时 的 相关 操作 ， 在 此 情况 下 驱动 可 以 通过 相应 接口 进行 相关 
操作 。 应 用 接口 层 利 用 该 功能 进行 相关 的 操作 ， 通 过 检测 总 线 控制 器 的 状态 变化 ， 进 行 2c. 
dev 以 及 设备 文件 的 创建 和 销毁 。 

PC 设备 更 多 的 是 对 内 核 的 各 种 功能 框架 提供 设备 的 控制 接口 ， 这 样 就 要 求 将 功能 框架 
设备 与 TC 设备 关联 。 以 视频 框架 为 例 ， 相 应 的 关联 是 在 v412_i2c_subdev_init 中 实现 的 ， 具 
体 细节 如 下 : 

















void v412_i2c_subdev_init( struct v4]2_subdev * sd, struct i2c_client * client, 


const struct v412. subdev. ops * ops) 


v4D. subdev. init(sd, ops) ; 

sd —» flags | = V4L2, SUBDEV. FL IS I2C; 

/ * the owner is the same as the i2c. client s driver owner * / 

sd —> owner = client —» driver —> driver. owner; 

/ * i2c client and v412. subdev point to one another * / 

[将 P.C 设备 与 VAL2 子 设备 关联 

v4I2. set. subdevdata( sd, client) ; 

i2c_set_clientdata( client, sd) ; 

/ * initialize name * / 

snprintf( sd -> name, sizeof(sd -> name) , "96s 96 d — % 04x" , 
client -> driver -> driver. name, i2c adapter. id( client -> adapter) , 
client -> addr) ; 


| 


DORE V412 子 设备 就 可 以 在 操作 中 通过 v412_get_subdevdata 来 获得 PC 设备 进行 相应 的 
HE, m PC 设备 移 除 时 也 可 以 通过 i2c_get_clientdata 来 获得 VAL2 子 设备 进行 释放 操作 。 

DORE PC 框架 就 分 别 给 内 核 功 能 模块 与 应 用 层 提 供 了 操作 接口 ， 在 该 设计 中 可 以 保证 共 
用 的 部 分 尽量 多 。 

2. 总 线 控制 器 相关 

PC 总 线 框架 对 总 线 控制 器 的 管理 主要 是 通过 2c adapter 来 实现 的 ， 其 详细 分 析 如 下 : 























struct i2c_adapter | 


struct module * owner; 











// 现 内 核 已 经 使 用 IDR(ID 号 与 指针 对 应 的 机 制 ) ID 不 建议 使 用 
unsigned int id __deprecated; 

// 总 线 功 能 类 型 ,有 一 般 控 制 类 型 HWMON .DDC( Display Data Channel) 以 及 
// SPD(Serial Presence Detect) 等 不 同类 型 

unsigned int class; / * classes to allow probing for * / 


/人 /总 线 控制 器 设备 特殊 的 操作 总 线 的 方法 
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接口 ， 通 


ls 


const struct i2c algorithm * algo; / * the algorithm to access the bus * / 
// 具 体 总 线 控制 器 所 需 的 私有 数据 


void * algo data; 























/ * data fields that are valid for all devices */ 

// 由 于 总 线 连接 多 个 设备 ,该 锁 保 护 单一 总 线 操作 的 原子 性 
struct rt_mutex bus_lock; 

// 超 时 值 ,超时 则 退出 传送 

int timeout; /* in jiffies */ 

// 单 一 总 线 操作 重 传 次 数 


int retries; 






































// 设 备 模 型 管理 

struct device dev; / * the adapter device */ 

]/ 设 备 中 总 线 控 制 器 的 编号 ,也 可 以 代表 总 线 编号 ,可 以 由 具体 设备 指定 
int nr; 


char name| 48 ] ; 


struct completion dev. released; 


struct mutex userspace, clients lock; 


struct list head userspace, clients; 











从 中 可 见 ， 除 了 属性 信息 外 最 重要 的 就 是 2e algorithm To i2e algorithm 中 定义 了 操作 
Be 


操作 接口 可 以 实现 标准 的 了 PC 总 线 操作 。 由 于 不 同 设备 的 操作 方法 不 同 ， 该 








接口 实际 


过 
是 


这 些 
实现 具体 设备 总 线 控制 器 的 总 线 操作 逻辑 。 下 面 来 看 看 具体 细节 : 





struct i2c_algorithm | 


bs 


/标准 工 C 总 线 传输 的 操作 接口 

int( * master_xfer) (struct i2c_adapter * adap, struct i2c_msg * msgs, int num) ; 

//smbus 传输 的 操作 接口 

int( * smbus_xfer) (struct i2c_adapter * adap, ul6 addr, unsigned short flags, 
char read. write, u8 command, int size, union i2c_smbus_data * data); 

/ * To determine what the adapter supports * / 

// KAS ARTE ie OC SEHE DRE , 28 E DIA EF DIE E Za RO I E 

// 是 否 满足 需求 ,功能 如 2C_FUNC_I2C 定义 在 ic.h 中 

u32( * functionality) ( struct i2c_adapter * ) ; 














从 中 可 见 ， 有 两 个 操作 接口 ， 但 是 两 个 并 不 都 需要 提供 ， 通 常 只 要 提供 标准 工 C 接口 
C 


master. xfer 即 可 。 通 过 标准 的 下 C 操作 可 以 模拟 smbus PEPE, P 


总 线 框架 提供 函数 i2c_sm- 








bus_xfer_emulated 来 模拟 相应 的 操作 。 在 一 次 传输 中 可 以 批量 做 多 次 处 理 ， 每 个 处 理 都 是 一 
次 i2c_msg 的 交互 操作 ， 具 体 2c_msg 的 个 数 由 参数 num 指定 。 
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为 了 管理 总 线 控制 器 ，PC 总 线 框架 提供 了 以 下 接口 ; 





// 由 系统 指定 总 线 控制 器 编号 进行 管理 

int i2c_add_adapter( struct i2c_adapter * ) ; 

// 需 要 按照 设备 指定 的 总 线 控制 器 编号 进行 管理 
int i2c_add_numbered_adapter( struct i2c_adapter * ); 











int i2c_del_adapter( struct i2c_adapter * ) ; 


具体 设备 的 总 线 控制 器 在 调用 以 上 接口 进行 管理 前 ， 相 关 的 属性 (包括 algo) 都 需要 初 
始 化 ， 也 就 是 说 框架 并 没有 提供 总 线 控制 器 的 操作 algo 与 管理 实体 adapter 进行 绑 定 的 接口 。 
这 是 由 于 adapter 的 很 多 属性 都 需要 初始 化 ， 而 与 哪个 操作 算法 绑 定 开发 者 最 清楚 ， 所 以 直 
接 作为 初始 化 的 一 部 分 设置 即 可 。 

另外 还 提供 了 adapter 设备 特殊 管理 数据 的 设置 和 获取 接口 ， 如 2e. set. adapdata 和 i2c_ 
get_adapdata, 

当 一 个 adapter 加 入 系统 后 ， 说 明 增 加 了 一 个 下 C 总 线 连接 ， 而 通常 PC 总 线 是 在 硬件 板 
上 直接 进行 连接 ， 这 就 需要 进行 总 线 的 遍历 以 及 总 线 设备 与 相应 驱动 的 绑 定 。 这 个 流程 是 在 
i2c_register_adapter 中 完成 的 ， 而 该 函数 会 在 i2c_add_adapter 和 i2c_add_numbered_adapter 中 
进行 调用 。i2c_register_adapter 中 主要 工作 就 是 进行 adapter 设备 模型 的 注册 ， 另 外 通过 如 下 
代码 进行 总 线 遍 历 : 






































mutex_lock( &core lock); 
bus, for each, drv( &i2e bus type, NULL, adap, _ process new, adapter) ; 


mutex, unlock ( &core_lock ) ; 


这 里 对 每 个 了 C 设备 驱动 都 执行 _process_new_adapter， 在 _process_new_adapter 中 会 通 
过 i2c_detect 调用 i2c_detect_address 来 由 驱动 detect 匹配 的 设备 。 如 果 detect 成 功 则 注册 新 
设备 。 其 中 设备 模型 和 总 线 会 负责 绑 定 驱动 ， 从 而 完成 加 载 操作 ， 这 就 实现 了 总 线 设备 发 现 
相关 功能 。 

总 线 的 主要 功能 (包括 总 线 传输 事务 以 及 总 线 设备 发 现 ) 就 都 在 了 PC 总 线 控制 器 部 分 有 
了 完整 的 支持 。 

3. 总 线 设 备 相 关 

PC 总 线 框架 提供 了 i2c_client 来 完成 总 线 设 备 管理 功能 ， 详 细 内 容 如 下 : 









































struct i2c_client | 


/指示 设备 的 特点 如 唤醒 系统 能 力 ,10bit 地 址 等 





unsigned short flags; / * div. , see below */ 
// 地 址 

unsigned short addr; /* chip address - NOTE: 7bit */ 
char name[ I2C. NAME, SIZE] ; 

// 关 联 的 总 线 视频 器 

struct i2c_adapter * adapter; / * the adapter we sit on */ 


593 


E 
从 相关 


/关联 的 总 线 驱动 














struct i2c_driver * driver; / * and our access routines * / 
/设备 模型 实体 

struct device dev; / * the device structure */ 
// 设 备 关 联 到 系统 的 中 断 号 ,通常 是 外 部 中 断 信号 或 者 gpio 

int irq; / * irq issued by device */ 


struct list head detected ; 








属性 来 看 ， 主 要 的 属性 是 addr 、adapter 和 driver。 下 面 来 看 看 与 之 相关 联 的 driv- 


er 的 详细 信息 : 
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struct i2c_driver | 


unsigned int class; 
// 在 总 线 控制 器 增加 或 减少 时 需要 进行 的 特殊 操作 
int( * attach, adapter) ( struct i2c_adapter * ) ; 


int( * detach, adapter) (struct i2c_adapter * ) ; 


/ * Standard driver model interfaces * / 
// 标 准 的 设备 模型 操作 ,用 于 设备 绑 定 的 初始 化 以 及 设备 移 除 的 资源 释放 


int( * probe) (struct i2c_client * , const struct i2c_device_id * ) ; 





























int( * remove) (struct i2c_client * ) ; 


/ * driver model interfaces that don t relate to enumeration */ 
// 电 源 管理 相关 接口 


void( * shutdown) (struct i2c_client * ); 























int( * suspend) (struct i2c_client * , pm message t mesg) ; 
int( * resume) (struct i2c, client * ); 

/协议 特殊 的 操作 

void( * alert) (struct i2c_client * , unsigned int data) ; 

// 设 备 特殊 的 命令 接口 


int( * command) (struct i2c_client * client, unsigned int cmd, void * arg) ; 


/人 /设备 模型 接口 
struct device_driver driver; 
// 支 持 设备 的 ID 表 , 主 要 是 name 


const struct i2c_device_id * id table; 








/ * Device detection callback for automatic device creation * / 
// 检 测 是 否 支 持 相 应 设备 
int( * detect) (struct i2c_client * , struct i2c_board_info * ); 


const unsigned short * address_list; 


struct list_head clients; 


l; 


从 i2c_driver 的 内 容 分 析 可 见 ， 其 主要 负责 总 线 相关 以 及 电源 管理 相关 的 操作 ， 操 作 接 
口中 并 不 涉及 实际 的 信息 传输 ， 可 以 说 该 驱动 主要 是 处 理 总 线 和 设备 模型 相关 的 事务 ， 并 不 
涉及 功能 的 事务 。 功 能 型 的 事务 涉及 操作 的 具体 内 容 ， 是 在 功能 型 驱动 中 通过 工 C 的 接口 实 
现 的 。 而 功能 型 的 事务 需要 有 总 线 设 备 的 信息 ， 这 就 要 求 功能 型 驱动 管理 实体 中 能 够 包含 
i2c client 的 信息 。 这 个 桥梁 是 与 工 C 总 线 事务 相关 的 ， 所 以 该 工作 自然 就 由 i2. driver 来 完 
成 ,具体 的 接口 就 是 probbe， 这 样 整体 上 各 种 实体 就 关联 起 来 了 。 具 体例 子 见 mt9t111_ 
probe: 


























static int mt9t111_probe( struct i2e, client * client, const struct i2e, device id * id) 
| 
struct mt9t111 * miOt111; 


int ret; 


/ * Check if the adapter supports the needed features */ 
// KAS S ER T n HE 3 S ST 
if( | i2c, check, functionality( client -> adapter, I2C. FUNC. SMBUS BYTE DATA))| 
v4l_err( client, " mt9t111; DPC Adapter doesn t support" V 
" [2C FUNC SMBUS WORDW"); 





return — EIO; 


//i2c. client 与 v412 子 设备 关联 
v412_i2c_subdev_init( &mt9t111 -> subdev, client, &mt9t111_ops) ; 


return ret; 


| 


只 有 总 线 设 备 与 功能 管理 实体 关联 后 才能 完成 功能 性 的 工作 ， 而 总 线 设 备 对 应 的 驱动 主 
要 工作 是 建立 总 线 设备 与 功能 管理 实体 的 关联 ; 对 物理 总 线 以 及 电源 管理 等 事件 响应 并 进行 
相应 的 操作 。 

以 上 无 论 是 i2c_client 还 是 i2c_driver 都 属于 PC 总 线 框架 管理 的 运行 时 的 实体 ， 而 下 C 
总 线 设备 通常 直接 焊接 在 板子 上 面 ， 这 些 固定 的 信息 同样 需要 进行 表示 ， 在 创建 动态 管理 的 
设备 实体 时 需要 这 些 信息 。 在 工 C 总 线 框架 中 相应 的 实体 是 i2c_board_info， 内 容 如 下 : 









































struct i2c_board_info | 
// 设 备 名 
eie type[ I2C. NAME, SIZE] ; 
/指示 设备 的 特点 如 唤醒 系统 能 力 .10bit 地 址 等 


unsigned short flags; 
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// 地 址 
unsigned short addr; 
// 特 殊 信息 ,会 作为 device 中 的 特殊 信息 传 给 了 了 C 驱动 做 处 理 


void * platform_data; 








struct dev_archdata * archdata; 





// 设 备 给 系统 的 中 断 信息 
int irq; 


E 





基本 的 信息 就 是 type 和 addr, FY LA DC BOARD INFO 来 产生 。 
XP PC 总 线 设备 的 创建 ， 框 架 提供 的 函数 接口 如 下 : 























// 已 知 设备 地 址 使 用 的 接口 


struct i2c_client * i2c_new_device( struct i2c_adapter * adap, 





struct i2c_board_info const * info) ; 
// 未 知 设备 地 址 使 用 的 接口 


struct i2c_client * i2e new. probed device( struct i2c_adapter * adap, 

















struct i2c. board. info * info, unsigned short const * addr list, 


int( * probe) (struct i2e, adapter * , unsigned short addr) ) 








从 中 可 见 ， 创 建 总 线 设 备 需 要 i2c_adapter 和 ic_board_info， 对 于 特定 总 线 设 备 有 i2c_ 
board_info 信息 ， 这 就 需要 明确 与 i2c_adapter 关联 。 

有 两 种 方法 来 实现 : 方法 一 通过 struct i2c_adapter * ic_get_adapter(int id) 获得 指定 的 
i2c_adapter， 然 后 调用 i2c_new_device 来 创建 总 线 设备 。 方 法 二 是 在 初始 化 阶段 调用 如 下 也 
数 ， 注 册 某 个 PC 总 线 上 的 所 有 设备 信息 : Dc register board, info( int busnum, struct i2c_ 
board, info const * info, unsigned len) ， 总 线 控制 需 i2c_adapter 会 通过 i2c_scan_static_board 
info 来 遍历 这 些 信 息 ,为 总 线 上 的 设备 创建 i2c_client。 

方法 一 主要 用 于 总 线 设备 信息 初始 化 晚 于 i2e adapter 初始 化 的 情况 ， 如 camer sensor 的 
v4l2 子 设备 ; 而 方法 二 则 是 用 于 较 早 初始 化 的 情况 。 

4. 总 线 传 输 接 口 

总 线 传输 是 完成 功能 型 事务 的 基础 ， 之 前 已 经 了 解 到 ， 一 次 总 线 传输 可 以 进行 多 个 i2c_ 
msg 的 交互 ，i2c_msg 是 传输 的 基本 信息 。 下 面 来 看 一 下 详细 内 容 : 









































struct i2c_msg | 
// 从 地 址 
. ul6 addr; / * slave address */ 
// 表 示 读 / 写 ,以 及 地 址 位 数 等 属性 
. ul6 flags; 
// 信 息 长 度 
_ul6 len; / * msg length * / 
/信息 数据 
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_u8 * buf; / * pointer to msg data ** / 


l; 





标准 工 C 传输 的 接口 函数 是 2e_transfer， 具 体内 容 如 下 : 


int i2c_transfer( struct i2c_adapter * adap, struct i2c msg * msgs, int num) 
| 
unsigned long orig_jiffies; 
int ret, try; 
// 使 用 master_xfer 进行 传输 操作 
if( adap —» algo —» master_xfer) | 
// 进 行 必要 的 锁 操 作 
if(in_atomic( ) || irqs_disabled( ) ) | 
ret = i2c_trylock_adapter( adap) ; 
// 原 子 操作 和 关中 断 不 能 等 待 长 时 间 的 操作 ,如 果 无 法 获得 锁 
// 则 报告 错误 
if( ! ret) 
/* [2C activity is ongoing. */ 
return — EAGAIN ; 





| else | 


i2c_lock_adapter( adap) ; 


/ * Retry automatically on arbitration loss * / 
orig jiffies = jiffies ; 
// 重 试 机 制 
for( ret 20, try 20; try < =adap —» retries; try ++ ) | 
/进行 实际 的 传输 
ret = adap —> algo —> master_xfer( adap, msgs, num) ; 
// 没 有 重 试 异常 则 跳出 重 试 
if( ret! = — EAGAIN) 
break ; 
// 超 时 则 跳出 重 试 
if( time_after( jiffies, orig_jiffies + adap —> timeout) ) 
break ; 


pa 





} 
/释放 锁 
i2c_unlock_adapter( adap) ; 


return ret; 
} else | 
dev. dbg( &adap -> dev, "I2C level transfers not supported n" ) ; 
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return - EOPNOTSUPP; 





从 代码 中 可 见 ， 实 现 一 定 的 重 传 和 超时 机 制 主要 还 是 通过 adapter 中 操作 接口 master_ 
xfer 来 完成 的 。 
具体 的 操作 通常 由 功能 型 驱动 完成 。 下 面 还 是 以 mt9t111 sensor 为 例 : 





static int mt9tl11_read_reg( struct i2c_client * client, ul6 reg, ul6 * val) 
| 

struct i2c msg msg[ 1]; 

u8 data[4]; 


int err; 














// 读 寄存 器 时 要 先 写 入 读 取 的 寄存 器 地 址 ,然后 再 进行 读 取 操作 
// 先 写 读 取 的 寄存 器 地 址 信息 


msg —> addr = client -> addr; 





msg —> flags =0; 
msg —> len =2; 
msg —> buf = data; 
data[ 0] = (reg & Oxff00) 258; 
data[ 1] = (reg & OxOOff) ; 
err = i2c_transfer( client -> adapter, msg, 1) ; 
if( err >=0) | 
// 进 行 读 操作 
msg —> flags = I2C M RD; 
msg —>len=2; / * 2 byte read */ 
err = i2c_transfer( client -> adapter, msg, 1) ; 
if(err >=0) } 
* val = ((data[0] & 0x00ff) <8) 
| Cdata[ 1] & 0x00ff) ; 


return 0; 


| 


return err; 


static int mt9t111_write_reg( struct i2c_client * client, ul6 reg, ul6 val) 
| 

struct i2c msg msg[ 1]; 

u8 data| 20] ; 


int err; 
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msg —> addr = client -> addr; 

msg —> flags =0; 

msg —> len =4; 

msg —> buf = data; 

data[ 0] = (u8) ( (reg & Oxff00) >>8) ; 

data[ 1] = (u8) (reg & 0x00ff) ; 

data[2] = (u8) ( (val & Oxff00) 258) ; 
data[3] = (u8) (val & 0x00ff) ; 

err = i2c_transfer( client -> adapter, msg, 1) ; 
if(err <0) 


return err; 


return 0; 











以 上 分 别 是 读 和 写 的 例子 ， 可 见 主要 的 工作 就 是 通过 2e client 的 信息 构建 i2c msg, $^ 
后 调用 12e. transfer 来 完成 传输 。 
为 了 免 去 驱动 构建 2c_msg， 框 架 提 供 了 以 下 接口 以 方便 驱动 调用 : 











int i2c_master_send( struct i2c_client * client, const char * buf, int count) ; 


int i2c_master_recv( struct i2c_client * client, char * buf, int count) ; 














CEE pBABE MT i2c_ transfer 的 封装 。Linux AY PC 框架 主要 提供 的 是 主 设备 的 功能 ， 而 
从 设备 功能 并 没有 涉及 ， 这 与 使 用 Linux 设备 通常 都 通过 工 C 总 线 连 接 从 设备 相关 。 


7.1.3 TI 芯片 了 了 C 总 线 驱 动 相 关 实 现 详解 


DM 3730 的 了 PC 控制 器 框架 如 图 7-4 所 示 。 图 7-4 引 自 《DM 3730 芯片 手册 》 中 第 
2798 页 的 框图 。 

从 图 7-4 可 见 ， 作 为 了 了 C 控制 器 即 可 以 做 master 也 可 以 做 slave, TE Linux 内 核 中 主要 是 
实现 master 的 功能 ，FIFO 用 于 进行 数据 缓冲 ， 可 以 通过 处 理 器 读 写 ， 也 可 以 通过 DMA 
读 写 。 

关于 DM 3730 FC 的 驱动 部 分 ， 主 要 分 析 相 关 初 始 化 和 总 线 传 输 的 操作 。 

1. 初始 化 

先 来 看 看 初始 化 部 分 ， 作 为 SoC 片 内 的 控制 器 ， 相 应 的 驱动 都 是 作为 platform driver 
存在 的 ， 在 系统 初始 化 时 会 注册 相应 的 platform device, MI% platform driver 的 probe PK Xt 
中 则 会 根据 platform device 的 信息 进行 初始 化 。 这 个 初始 化 是 十 分 重要 的 ， 现 在 就 来 详细 
了 解 其 内 容 。 
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7-4 DM 3730 PC 控制 器 框图 





static int __devinit omap_i2c_probe( struct platform. device * pdev) 


| 


struct omap_i2c_dev * dev; 
struct i2c_adapter * adap; 
struct resource * mem, * irq, * ioarea; 


struct omap_i2c_bus_platform_data * pdata = pdev —> dev. platform_data; 
irq_handler_t isr; 
int T; 


u32 speed =0; 


/ * NOTE; driver uses the static register mapping * / 
// 获 得 寄存 器 空间 信息 
mem = platform_get_resource( pdev, IORESOURCE MEM, 0) ; 





// 获 得 中 断 信息 
irq = platform. get resource( pdev, IORESOURCE IRQ, 0) ; 


/在 内 核 的 地 址 空间 管理 中 标记 寄存 器 空间 使 用 . 


ioarea = request_mem_region( mem —> start, resource_size(mem) , pdev —» name) ; 


// 分 配 管理 实体 
dev = kzalloc( sizeof( struct omap_i2c_dev) , GFP_KERNEL) ; 
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//DM 3730 特殊 操作 实体 , 明确 总 线 速 度 和 处 理 器 的 唤醒 延 时 
if( pdata! 2 NULL) | 

speed = pdata —> clkrate; 

dev —> set. mpu. wkup. lat = pdata -> set, mpu, wkup lat ; 
| else | 

speed = 100; / * Default speed * / 

dev -> set_mpu_wkup_lat = NULL; 





/向 管理 实体 中 的 属性 赋值 
dev -> speed = speed; 
dev -> idle =1; 


dev -> dev = &pdev -> dev; 








dev -> irq = irq —> start; 
// 寄 存 咒 空间 映射 到 内 核 虚 拟 空间 
dev -> base = ioremap( mem —> start, resource, size( mem) ) ; 
if( ! dev —> base) | 
r= - ENOMEM; 
goto err free mem; 


| 
// 设 置 platform device 的 私有 数据 
platform, set. drvdata( pdev, dev); 


// R EAT E YAR fL. Bd SCR FY SD A , AA Tr] ae n UT 
if( cpu, is; omap7xx( ) ) 
dev -> reg shift =1; 
else if( epu, is omap44xx( ) || cpu. is. tiSlxx( ) ) 
dev -> reg shift 20; 
else 


dev -> reg shift 22; 


if( cpu_is_omap44xx() || epu, is, tiS1xx( ) ) 
dev —»regs = (u8 * ) omap4 reg map; 
else 


dev -> regs = (u8 * ) reg map; 


// enable 设备 runtime pm 功能 

pm. runtime, enable( &pdev -> dev) ; 

// 激 活 P C 控制 器 使 其 处 于 active 状态 
omap_i2c_unidle( dev) ; 


// 读 取 硬 件 版 本 
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dev —> rev = omap_i2c_read_reg(dev, OMAP I2C REV REG) & Oxff; 
/记录 可 能 的 勘误 
if( dev -> rev < =OMAP_I2C_REV_ON_3430) 

dev —» errata | = I2C_OMAP3_1P153; 


// 根 据 版 本 获得 fifo size 并 计算 延 时 
if(! (cpu_class_is_omapl() || cpu_is_omap2420() ) ) | 
ul6 s; 


/ * Set up the fifo size — Get total size */ 
s = ( omap. i2c, read, reg( dev, OMAP I2C BUFSTAT REG) >14) & 0x3; 


dev —> fifo_size 2 0x8 «« s; 


if( dev -> rev >= OMAP I2C REV. ON 4430) | 

dev —> fifo, size 20; 

dev -» b hw 20; / * Disable hardware fixes * / 
| else | 

dev —> fifo. size = (dev —> fifo size / 2) ; 

dev -»b hwz1; /* Enable hardware fixes ** / 
| 
/ * calculate wakeup latency constraint for MPU * / 
if( dev —> set mpu, wkup lat! = NULL) 

dev -> latency = (1000000 * dev —» fifo size) / 

(1000 * speed / 8) ; 


/ * reset ASAP, clearing any IRQs */ 
//reset VC 控制 器 ,清除 中 断 , 保 证 控制 器 处 于 已 知 状态 


omap_i2c_init( dev) ; 








// 设 置 中 断 处 理 函 数 
isr = (dev -» rev < OMAP I2C REV 2) ? omap_i2c_revl_isr : omap_i2c_isr; 





r = request, irq( dev —» irq, isr, 0, pdev -> name, dev); 


// 人 允许 设备 idle 
omap_i2c_idle( dev) ; 





// (i) P.C 框架 注册 T C 适配器 实体 
adap = &dev -> adapter; 
i2c_set_adapdata( adap, dev) ; 

adap -> owner = THIS_MODULE; 
adap —» class = I2C. CLASS. HWMON ; 
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strlepy( adap -> name, "OMAP I2C adapter" , sizeof( adap -> name) ) ; 
/设备 相关 的 工 C 传输 操作 接口 实体 

adap -> algo = &omap_i2c_algo; 

adap -> dev. parent = &pdev -> dev; 





// 总 线 控制 器 编号 设置 为 了 PC 控制 器 编号 
adap -> nr = pdev -> id; 

// 指 定编 号 注册 

r = i2c_add_numbered_adapter( adap) ; 





return 0; 


err_free_irq: 


return r; 





probe 中 需要 的 platform device 是 在 omap2. i2c, add, bus 中 进行 初始 化 的 ， 主 要 内 容 
如 下 : 


static inline int omap2_i2c_add_bus( int bus, id) 
| 
int l; 
struct omap_hwmod * oh; 
struct omap_device * od; 
char oh_name[ MAX_OMAP_I2C_HWMOD_NAME_LEN |; 


struct omap_i2c_bus_platform_data * pdata; 





// 引 脚 设置 
omap2_i2c_mux_pins( bus id); 
/AKf3 Y C 控制 器 名 
l = snprintf( oh name, MAX. OMAP I2C HWMOD. NAME LEN, "i2c96d" , bus id) ; 
// 获 得 相应 的 硬件 模块 信息 
oh = omap_hwmod_lookup(oh_name ) ; 
if(! oh) | 
pr. err( " Could not look up % s\n" , oh. name) ; 
return — EEXIST; 











pdata = &i2c_pdata[ bus id - 1]; 


if( cpu. is. omap34xx( ) ) 
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pdata -> set_mpu_wkup_lat = omap. pm. set, max, mpu, wakeup. lat, compat ; 
// 这 里 会 创建 platform device 并 注册 


od = omap. device, build( name, bus id, oh, pdata, 























sizeof( struct omap. i2c, bus platform, data) , 
omap. i2e latency, ARRAY. SIZE( omap. i2e latency) , 0) ; 
WARN(IS ERR(od) , "Could not build omap. device for % s\n", name); 


return PTR, ERR( od) ; 
| 





REES TCO 控制 器 相关 的 初始 化 ， 总 线 设备 的 初始 化 是 由 DM 3730 提供 相应 的 接口 ， 
通过 omap_register_i2c_bus 来 实现 的 ， 具 体 细节 如 下 : 








int. init omap_register_i2c_bus(int bus, id, u32 clkrate, 


struct i2c. board. info const * info, unsigned len) 
int err; 


if( info) | 
// 3k Hil zt PC 框架 注册 静态 的 2c. board, info ,后 续 注 册 adapter 时 
// 会 根据 这 些 信息 创建 总 线 设 备 管理 实体 
err =i2c_register_board_info(bus_id，info，len ) ; 
if( err) 


return err; 
































} 
// 如 果 没 有 初始 化 总 线 频率 , 则 使 用 传人 的 参数 
if( ! i2c_pdata[ bus, id — 1 ]. clkrate) 

i2c_pdata[ bus, id - 1 ]. clkrate = clkrate; 





i2c_pdata[ bus, id - 1]. clkrate & = ~ OMAP I2C CMDLINE SETUP; 
/ hd P.C 控制 器 信息 进行 platform device 的 初始 化 
return omap_i2c_add_bus(bus_id) ; 





| 


关于 工 C 总 线 的 频率 ， TI 为 其 提供 了 启动 参数 设置 的 接口 ， 可 以 在 bootargs 中 加 入 命令 
i2c_bus = bus. id ,clkrate( in kHz) 来 进行 总 线 频率 的 设置 ， 具体 的 总 线 频率 设置 是 在 omap_i2c 
init 中 进行 的 。 提 供 参数 设置 的 好 处 是 : 一 些 硬件 问题 可 以 通过 调整 总 线 频率 验证 或 者 解 
决 ， 有 了 参数 设置 接口 ， 就 可 以 避免 代码 的 修改 和 编译 等 费时 的 工作 。 

2. 总 线 传输 

总 线 传输 是 由 omap_i2c_algo 描述 的 ， 细 节 如 下 : 

















static const struct i2c. algorithm omap_i2c_algo = | 


. master_xfer = omap_i2c_xfer, 
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l; 


. functionality = omap_i2c_func, 


主要 是 传输 接口 omap_i2c_xfer， 下 面 对 传 输 过 程 进 行 详细 分 析 : 


static int omap_i2c_xfer( struct i2c_adapter * adap, struct i2c_msg msgs[ |, int num) 


| 


out: 


| 


struct omap_i2c_dev * dev = i2c_get_adapdata( adap) ; 
int 1; 
int r; 
// SRAUELE till tit active 
omap_i2c_unidle( dev) ; 
/等 待 总 线 空 闲 
r = omap_i2c_wait_for_bb( dev) ; 
if(r <0) 
goto out; 
// 对 所 有 的 msg 进行 传输 
for(i=0; i «num; i++) | 
// 根 据 是 否 是 最 后 一 个 msg ,表示 是 否 加 stop condition 
r = omap_i2c_xfer_msg( adap, &msgs[i],(i22 (num- 1))); 
if(r! =0) 
break; 








if(r ==0) 

r=num; 
/等 待 总 线 空闲 则 结束 
omap_i2c_wait_for_bb( dev) ; 








omap_i2c_idle( dev) ; 


return r; 


msg 的 传输 是 通过 omap_i2c_xfer_msg 来 完成 的 ， 下 面 来 看 看 具体 实现 过 程 : 





static int omap_i2c_xfer_msg( struct i2c_adapter * adap, struct i2c_msg * msg, int stop) 


| 


// 首 先 获 得 相应 的 了 C 控制 器 的 管理 实体 


struct omap_i2c_dev * dev = i2e get. adapdata( adap) ; 








int T; 


ul6 w; 


if( msg —> len 220) 
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return — EINVAL; 
/传输 操作 的 从 设备 地 址 写 人 寄存 器 
omap. i2c write reg( dev, OMAP_I2C_SA_REG, msg -> addr) ; 





// 将 msg 的 数据 信息 和 长 度 转 给 驱动 做 后 续 的 处 理 

dev -> buf = msg —> buf; 

dev -> buf len = msg —> len; 

// 写 payload 长 度 计数 寄存 器 

omap. i2c write reg( dev, OMAP_I2C_CNT_REG, dev -> buf len) ; 


/ * Clear the FIFO Buffers ** / 

/操作 之 前 ,需要 把 FIFO 清空 

w = omap_i2c_read_reg(dev, OMAP DC BUF REG); 

w |20MAP DC BUF RXFIF CLR | OMAP I2C BUF TXFIF CLR; 
omap. i2c. write reg( dev, OMAP I2C BUF REG, w); 














// 初 始 化 completion ,用 于 操作 同步 


init_completion( &dev -> cmd, complete) ; 





dev -> cmd_err =0; 


//enable 控制 器 ,设置 master 和 start condition (总线 传 输 起 始 标记 ) 
w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT; 





/ * High speed configuration * / 
// 总 线 速 度 大 于 400K 就 是 HS 模式 
if( dev —> speed > 400) 
w |=OMAP_I2C_CON_OPMODE_HS; 
// 如 果 10bit 地 址 需要 进行 设置 
if( msg —> flags & I2C_M_TEN) 
w |= OMAP. DC CON. XA; 
// 如 果 是 写 操作 ,需要 设置 为 transmit mode 
if(! (msg -> flags & I2C M, RD)) 
w |= OMAP DC CON TRX; 








// 没 有 人 硬件 bug 的 芯片 ,在 最 后 一 个 msg 需要 设置 stop condition 
/人 /用 于 结束 时 控制 器 发 送 传输 结束 标记 
if( ! dev -» b. hw && stop) 

w |= OMAP. DC CON STP; 





























// 将 上 述 总 线 操作 特性 写 和 控制 寄存 器 ,设置 了 控制 器 enable 就 开始 与 
// 从 设备 进行 通信 了 
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omap_i2c_write_reg( dev, OMAP_I2C_CON_REG, w); 
// 某 些 芯片 是 不 能 同时 设置 STT 和 STP 的 ,这 样 在 结尾 msg 时 需要 分 开设 置 
if( dev -» b hw && stop) | 

unsigned long delay = jiffies + OMAP I2C TIMEOUT; 

ul6 con = omap_i2c_read_reg( dev, OMAP_I2C_CON_REG) ; 

//STT 会 在 start condition 产生 后 被 清除 ,这 里 等 待 被 清除 

while( con & OMAP_I2C_CON_STT) | 

con = omap_i2c_read_reg( dev, OMAP_I2C_CON_REG) ; 








/ * Let the user know if i2c is in a bad state * / 
if( time, after( jiffies, delay) ) | 
dev. err( dev -> dev, "controller timed out " 
"waiting for start condition to finish Vn" ) ; 
return - ETIMEDOUT; 
| 
cpu. relax( ) ; 
| 
// 单 独 设置 STP 来 产生 stop condition 
w |= OMAP. DC CON STP; 
w & = -OMAP DC CON STT; 
omap. i2c, write reg( dev, OMAP I2C CON REG, w); 


if( dev -> set mpu. wkup lat! = NULL) 
dev -> set, mpu, wkup. lat( dev -> dev, dev —> latency) ; 
// 等 待 操作 完成 
r = wait for completion timeout( &dev -> cmd. complete, OMAP_I2C_TIMEOUT) ; 
if( dev —> set mpu. wkup lat! = NULL) 
dev -> set, mpu, wkup. lat(dev -> dev, - 1) ; 
/数据 长 度 改 为 0 


dev -> buf len 20; 





if(r <0) 

return r; 
// 超 时 则 reset 控制 器 
AC m0 1 


dev. err( dev —» dev, "controller timed out\n" ) ; 
omap. i2c. init( dev) ; 
return - ETIMEDOUT; 

| 

/正常 则 返回 

if(likely(!dev -> cmd_err) ) 


607 


return 0; 


/ * We have an error * / 
// HER overflow 或 者 underrun 等 错误 则 reset 控制 需 
if(dev -> cmd, err & (OMAP_I2C_STAT_AL | OMAP DC STAT ROVR | OMAP_I2C_STAT_ 
XUDF) ) | 
omap_i2c_init(dev) ; 
return 一 上 IO ; 
| 
// 没 有 等 到 ACK 则 特别 处 理 
if( dev -> cmd, err & OMAP_I2C_STAT_NACK) | 
// AR ZANE nak 则 直接 返回 
if( msg —> flags & I2C M IGNORE NAK) 
return 0; 
// YE 3 stop condition 的 情况 重 发 stop condition 
if( stop) | 
w =omap_i2c_read_reg( dev, OMAP I2C CON REG); 
w |= OMAP. DC. CON. STP; 
omap. i2e write reg( dev, OMAP I2C CON REG, w); 
| 
return - EREMOTEIO; 
| 


return — EIO; 





这 里 主要 是 根据 msg BJ PEXET TT ae SEA DE EL, KRAI EERE TE HF BAe RE p c rh 
执行 。 详 细 分 析 如 下 : 


static irqreturn_t omap_i2c_isr(int this irq, void * dev. id) 
struct omap_i2c_dev * dev = dev. id; 
ul6 bits; 
ul6 stat, w; 


int err, count =0; 


if( dev —> idle) 
return IRQ_NONE; 
// 读 取 enable HYP Wr 
bits = omap_i2c_read_reg( dev, OMAP_I2C_IE_REG) ; 
// 处 理 所 有 已 经 enable 并 且 上 报 事件 的 中 断 , 这 里 相当 于 轮 询 操作 
while( (stat = (omap_i2c_read_reg( dev, OMAP I2C STAT REG))) & bits) | 
dev. dbg( dev -> dev, "IRQ(ISR =0x% 04x) Vn" stat) ; 
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// 中 断 处 理 占 用 太 长 时 间 ,需要 退出 
if(count ++ ==100) | 
dev_warn( dev -> dev, "Too much work in one IRQ\n" ) ; 


break ; 








err =0; 
complete : 
// Tel BAR GS  , PRUELE nil ie SEC DA ds , BEBE itis Bos Bel BR 
omap. i2c, write reg( dev, OMAP I2C STAT REG, stat & 
~ (OMAP I2C STAT RRDY | OMAP. DC, STAT RDR | 
OMAP I2C STAT XRDY | OMAP. DC. STAT XDR)); 

// NACK 问题 则 重 发 
if( stat & OMAP_I2C_STAT_NACK) | 

err |= OMAP_I2C_STAT_NACK; 

omap_i2c_write_reg( dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_STP) ; 





| 
// 特 殊 的 错误 进行 记录 
if( stat & OMAP_I2C_STAT_AL) | 
dev. err( dev -> dev, " Arbitration lost\n" ) ; 
err | -OMAP. C. STAT AL; 
| 
// ARDY 状态 表示 操作 完成 ,其 他 不 可 恢复 错误 的 情况 时 , 则 报告 完成 操作 
// 之 前 已 经 对 错误 进行 记录 
if(stat &( OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL) ) | 
// 通 知 操作 完成 前 进行 后 续 的 清除 操作 
omap_i2c_ack_stat( dev, stat & 
(OMAP DC STAT RRDY | OMAP_I2C_STAT_RDR | 
OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR) ) ; 


























omap_i2c_complete_cmd( dev, err) ; 


return IRQ. HANDLED; 


// 进 行 数据 接收 操作 
if(stat &( OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR) ) Í 
u8 num bytes =1; 
// 勘 误 的 workaround 
if( dev —> errata & I2C_OMAP_ERRATA 1207 ) 
i2c. omap. errata, i207 (dev, stat) ; 
// 根 据 fifo 的 情况 来 确定 后 续 操 作 的 byte 数目 
if( dev —> fifo_size ) | 
//RRDY 说 明 还 需要 接收 的 数目 大 于 国 值 , 则 以 国 值 为 单位 接收 
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if(stat & OMAP I2C STAT RRDY) 
num, bytes = dev —> fifo_size; 

else / * read RXSTAT on RDR interrupt * / 
//receive drain 表示 还 应 读 取 byte 的 数目 








num, bytes = ( omap_i2c_read_reg( dev, 
OMAP I2C BUFSTAT REG) >>8) & Ox3F; 
| 
// 一 次 操作 fifo 中 的 byte 数 
while( num, bytes) | 
num bytes ——- ; 
// 读 出 数据 
w = omap_i2c_read_reg( dev, OMAP_I2C_DATA_REG) ; 
// 检 查 是 否 到 设 定 的 操作 数据 长 度 
if( dev —> buf len) | 
// 将 读 取 的 数据 写 入 设 定 的 空间 
* dev -» buf ++ =w; 


dev -> buf len —- ; 


| else | 
/7 预定 操作 而 此 时 仍 有 数据 要 操作 则 根据 中 断 情况 提示 
if(stat & OMAP_I2C_STAT_RRDY ) 
dev. err( dev -> dev, 
" RRDY IRQ while no data" 
" requested Wn" ) ; 
if( stat & OMAP I2C STAT RDR) 
dev. err( dev -> dev, 
"RDR IRQ while no data" 


" requested n" ) ; 


break ; 


// 清 除 状态 
omap_i2c_ack_stat( dev, 


stat &(OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR) ) ; 
// 重 新 查询 状态 寄存 器 ,再 开始 操作 


continue ; 

















| 

// 这 里 是 进行 写 的 操作 

if( stat &( OMAP_I2C_STAT_XRDY | OMAP. DC STAT XDR))| 
u8 num bytes 21; 
// 根 据 fifo 的 状态 设 定 一 次 操作 的 数目 
if( dev —> fifo_size) | 








//XRDY 说 明 还 需要 传送 的 数目 大 于 国 值 , 则 以 国 值 为 单位 接收 

if( stat & OMAP I2C STAT XRDY) 
num, bytes = dev —> fifo_size; 

else / * read TXSTAT on XDR interrupt * / 
// transmit drain 表示 还 应 发 送 byte 的 数目 
num_bytes = omap_i2c_read_reg( dev， 


OMAP I2C BUFSTAT REG) & 0x3F; 





| 
// 进 行 一 次 操作 
while( num, bytes) | 
num bytes —- ; 
w 20; 
// 检 查 是 否 到 设 定 的 操作 数据 长 度 
if( dev —> buf len) | 
// 准 备 将 设 定 空间 的 数据 写 入 寄存 带 
w= *dev—>buf++; 


dev —>buf_len —-; 


| else | 
/ TARE BRNE T ECTS US OH EE E UU SS P Br DAS 
if( stat & OMAP I2C STAT XRDY) 
dev. err( dev -> dev, 
"XRDY IRQ while no " 
"data to send Wn" ) ; 
if( stat & OMAP I2C STAT XDR) 
dev. err( dev -> dev, 
"XDR IRQ while no " 
"data to send Wn" ) ; 
break ; 
| 


// 传 送 的 数据 写 人 寄存 器 
omap_i2c_write_reg( dev, OMAP I2C DATA, REG, w); 
| 
/清除 状态 
omap_i2c_ack_stat(dev, 
stat &(OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR) ) ; 
// 重 新 查询 状态 寄存 器 ,再 开始 操作 


continue ; 




















| 
// 其 他 异常 进行 标记 
if( stat & OMAP_I2C_STAT_ROVR) | 
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dev. err( dev -> dev, "Receive overrun\n" ) ; 
dev -> emd, err |  OMAP. DC, STAT. ROVR; 

| 

if( stat & OMAP I2C STAT XUDF) | 
dev. err( dev -> dev, "Transmit underflow\n" ) ; 


dev —» emd. err | = OMAP_I2C_STAT_XUDF; 


| 


return count ? IRQ_HANDLED : IRQ_NONE; 
} 


从 代码 中 可 见 ， 主 要 的 数据 操作 都 是 在 中 断 中 进行 处 理 的 。 由 于 工 C 作为 控制 和 获取 状 
态 信息 ， 数 据 量 并 不 大 ， 而 且 相关 的 操作 频率 并 不 高 ， 这 样 在 中 断 中 进行 相关 的 处 理 ， 对 系 
统 的 影响 并 不 大 。 

在 中 断 处 理 中 涉及 的 FIFO 阔 值 以 及 使 能 的 中 断 都 是 在 omap_i2c_init 中 进行 操作 的 ， 相 
关 代码 如 下 : 


if( dev —> fifo_size) | 
/ * Note; setup required fifo size ~ 1. RTRSH and XTRSH */ 
buf = (dev -> fifo size - 1) ««8 | OMAP. I2C. BUF. RXFIF CIR | 
(dev —> fifo size - 1) | OMAP. DC BUF TXFIF CLR; 
omap. i2c write reg( dev, OMAP D2C BUF REG, buf); 


/ * Enable interrupts * / 

dev —> iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY | 
OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL) | ( (dev -> fifo size) ? 
OMAP_I2C_IE_XDR) : 0); 

omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev -> iestate) ; 


OMAP ID2C IE ARDY | 
(OMAP I2C IE RDR | 


这 样 整个 的 传输 从 设置 到 实际 操作 就 完整 了 。 
7.1.4 PC 总 线 驱动 电源 管理 相关 说 明 


关于 PC 总 线 的 电源 管理 ， 首 先 来 看 看 bus_type 中 描述 的 总 线 级 别 的 电源 管理 操作 2e 
device_pm_ops， 细 节 如 下 : 


static const struct dev_pm_ops i2c_device_pm_ops = | 





. suspend = i2c_device_pm_suspend , 
. resume = i2c_device_pm_resume , 
. freeze = i2c_device_pm_freeze , 


. thaw = i2c_device_pm_thaw, 
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. poweroff = i2c_device_pm_poweroff ， 

. restore = i2c_device_pm_restore , 

SET_RUNTIME_PM_OPS( 
pm_generic_runtime_suspend, 
pm. generic runtime resume, 


pm. generic, runtime idle 


E 





其 中 包括 了 SLM Fil runtime pm 的 操作 接口 runtime pm 是 标准 接口 ， 用 于 调用 设备 模型 
device, driver 中 相应 的 操作 接口 ， 通 常 并 不 定义 。 下 面 以 suspend 操作 为 例 看 看 具体 的 操作 
2H :; 








static int i2c device pm, suspend(struct device * dev) 
| 
// 获 得 设备 模型 中 驱动 的 pm 操作 接口 


const struct dev_pm_ops * pm = dev —» driver ? dev —> driver -> pm : NULL; 











T 




















// 如 果 设 备 模 型 中 已 经 定义 了 操作 , 则 以 设备 模型 为 
if(pm) | 
// 检 查 设备 状态 ,如 果 在 suspend 状态 则 返回 ,否则 执行 接口 操作 并 返回 


if( pm_runtime_suspended( dev) ) 





return 0; 
else 
return pm —> suspend ? pm —» suspend( dev) : 0; 
} 
// #44 P C 的 suspend 操作 
return i2c_legacy_suspend( dev, PMSG_SUSPEND) ; 
} 


常 都 会 执行 了 C 相关 的 操作 ， 下 面 来 看 看 具体 的 实现 过 程 : 





- 


static int i2c legacy, suspend( struct device * dev, pm, message. t mesg) 


| 
// 转 换 为 总 线 设 备 
struct i2c_client * client =i2c_verify_client( dev); 


struct i2c_driver * driver; 


if( ! client || ! dev -> driver) 
return 0; 
// 转 换 为 总 线 驱 动 
driver = to_i2c_driver( dev -> driver) ; 


if( | driver —> suspend ) 
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return 0; 
// 执 行 驱 动 的 suspend 操作 
return driver —> suspend( client, mesg) ; 


| 


可 见 最 终 需 要 执行 2c driver 的 电源 管理 操作 。 

总 线 级 别 的 电源 管理 通过 i2c_driver 中 的 电源 管理 接口 进行 实际 操作 ， 而 对 于 SLM 操作 
中 的 设备 遍历 则 是 在 设备 模型 级 别 进 行 的 。 

控制 絮 级 别 的 电源 管理 通过 platform driver 来 进行 定义 ， 具 体 到 DM 3730 就 是 omap_i2c_ 
driver， 具 体 的 实现 中 设备 模型 的 实体 driver 中 并 没有 定义 pm 相关 的 操作 。 这 并 不 代表 没有 
在 控制 器 级 别 进行 电源 管理 操作 ， 控 制 器 有 platform device 实体 ， 在 设备 模型 级 别 会 执行 
platform bus 的 电源 管理 操作 ， 其 中 就 会 进行 实际 的 电源 管理 操作 。DM 3730 相关 的 部 分 在 
SoC 电源 管理 中 会 进行 详细 的 分 析 说 明 。 

DE PC 总 线 的 电源 管理 各 个 层面 就 完整 了 。 























7.2 串 行 外 设 接口 总 线 (SPI) 


7.2.1 SPI 总 线 驱 动 需求 


串 行 外 围 设备 接口 (Serial Peripheral Interface, SPI) 是 Motorola 首先 在 其 
MC68HCXX 系列 处 理 器 上 定义 的 。SPI 接口 主要 用 于 处 理 器 与 EEPROM, FLASH, 
WLAN 等 设备 的 连接 。SPI 是 一 种 高 速 、 全 双 工 、 同 步 总 线 。 连 接 方面 共 需 要 四 根 线 ， 
有 线 数 少 、 为 PCB 的 布局 上 节省 空间 的 优点 。SPI 速率 通常 介 于 1 ~70 MHz 之 间 ， 字 长 
范围 可 以 设置 从 4 ~32 bits, 

SPI 以 主 从 方式 工作 ， 通 常 有 一 个 主 设备 和 一 个 或 多 个 从 设备 ， 有 4 个 信号 ， 分 别 是 
MOSI, MISO, SCLK 和 CS 信和 号， 下 面 分 别 介绍 : 

e MOSI( Master Out Slave In) : 主 器 件数 据 和 输出， 从 需 件 数据 输入 。 

* MISO( Master In Slave Out); 主 占 件数 据 输 入 ， 从 器 件数 据 输 出。 

e SCLK : 时 钟 信号 ， 由 主 器 件 产 生 。 

e CS. 从 器 件 使 能 信号 ， 由 主 器 件 控制 。 

其 中 CS 控制 从 设备 是 否 被 选中 ， 只 有 片 选 信号 为 预先 规定 的 使 能 信号 时 (高 电位 或 低 
电位 ) ， 对 应 从 设备 的 操作 才 有 效 。 这 样 就 允许 单个 SPI 总 线 上 连接 多 个 SPI 从 设备 。 需 要 
注意 的 是 ， 单 总 线 连接 多 个 从 设备 时 需要 多 个 CS 信号 源 ， 具 体 可 以 使 用 GPIO 来 代替 控制 
器 的 CS 信号 (如果 控制 器 信号 不 足 )。 对 于 SPI 总 线 从 设备 并 没有 固化 的 地 址 ， 而 是 通过 
CS 信号 区 分 不 同 的 设备 。 

SPI 总 线 数据 传输 信号 规范 如 图 7-5 所 示 。 图 7-5 引 自 《DM 3730 芯片 手册 》 中 第 
2992 页 框图 。 

从 图 7-5 可 见 ， 信 和 号 的 极 性 、 相 位 等 性 质 是 可 以 配置 的 ， 而 对 于 传输 的 主 从 双方 也 是 
可 以 同时 进行 数据 传输 的 ， 这 些 功 能 都 是 必需 的 。 另 外 因为 SPI 总 线 频率 最 高 可 以 达到 70 
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图 7-5 SPI 总 线 数据 传输 信 


号 规范 


， 所 以 需要 较 大 吞吐 量 的 操作 方案 进行 数据 传输 ， 通 常 使 用 DMA 进行 操作 。 


系统 对 于 SPI 总 线 驱动 的 需求 就 是 要 


WF PC 总 线 的 各 种 无 关 性 需求 。 
7.2.2 SPI 总 线 驱 动 框架 解析 


. 总线 相关 以 及 核心 框架 
esi 先 来 了 解 SPL 总 线 的 实现 。 在 介 





能 实现 总 线 的 各 种 功能 ， 并 且 满 足 类 


儿 系 统 初始 化 的 时 候 ， 整 个 SPI 的 初 


始 化 函数 spi_init XE X. 7J postcore. initcall, Kod SPI 总 线 在 SPI 设备 或 者 驱动 注册 之 前 
进行 注册 ， 从 而 确保 总 线 的 功能 。 初 始 化 中 包含 如 下 语句 : 


status = bus register( &spi bus type); 


这 里 注册 了 总 线 类 型 ， 其 中 bus register 设置 总 线 自动 probe 功能 。 而 spi. bus. type 作为 


了 解 整个 总 线 框架 的 入 口 ， 详 细 定 义 如 下 : 


struct bus type spi bus type = | 


. name zu . 

. dev. attrs = spi_dev_attrs , 

. match = spi match, device, 
. uevent = spi, uevent, 


. suspend = spi. suspend, 
. resume -spi resume, 


ls 


这 里 重点 的 接口 是 mateh。 下 面 详 细 分 析 该 接口 : 
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static int spi_match_device(struct device * dev, struct device driver * drv) 
const struct spi device ^ * spi = to. spi. device( dev) ; 


const struct spi. driver * sdrv = to. spi. driver( drv) ; 


/ * Attempt an OF style match */ 
if( of. driver. match, device( dev, drv) ) 


return 1; 


// 如 果 有 支持 的 id_table 则 进行 比较 
if( sdrv —> id. table) 
return! | spi. match, id( sdrv —» id. table, spi) ; 





/名字 相同 则 匹配 
return stremp( spi -> modalias, drv -> name) ==0; 


| 








从 分 析 中 可 见 ， 主 要 就 是 进行 名 字 匹 配 。 这 里 并 没有 像 了 C 验证 设备 类 型 ， 这 是 为 什么 
WE? 难道 总 线 控制 器 不 是 设备 吗 ? 总 线 控制 器 还 是 设备 ， 但 是 SPI 的 实现 方式 不 同 ， 在 初始 
化 函数 spi_init 中 有 如 下 代码 : 








status = class register( &spi_master_class ) ; 


这 里 创建 了 class 功能 类 ， 总 线 控制 器 作为 class 设备 进行 管理 ， 而 match 只 是 匹配 相同 
bus 的 设备 ， 这 样 总 线 控制 器 设备 就 不 会 进行 match 操作 了 。 总 线 进行 匹配 的 设备 是 spi de- 
vice， 这 就 是 总 线 连 接 设 备 的 管理 实体 。 

在 spi. bus, type 中 并 没有 看 到 probe 接口 probe 操作 是 match 之 后 就 需要 进行 的 操作 ， 
主要 有 设备 特殊 资源 的 探测 、 申 请 以 及 初始 化 的 操作 。SPI 总 线 是 如 何 实现 该 功能 的 呢 ? 下 
面 来 看 看 对 应 的 spi_driver 注册 的 操作 : 























int spi register driver(struct spi driver * sdrv) 
| 
sdrv —> driver. bus = &spi_bus_type; 
if( sdrv -> probe) 
sdrv —> driver. probe = spi, drv. probe; 
if( sdrv -> remove) 
sdrv —> driver. remove = spi, drv. remove ; 
if( sdrv —> shutdown) 
sdrv —> driver. shutdown = spi. drv. shutdown; 


return driver register( &sdrv —> driver) ; 
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这 里 直接 将 接口 赋值 给 驱动 的 接口 ， 在 设备 模型 的 统一 操作 中 如 果 找 不 到 总 线 相关 的 接 


口 就 会 执行 driver 的 接口 ， 这 样 问题 就 解决 了 。 与 PC 比较 又 是 不 同 的 实现 方式 。 系 统 提 供 





了 统一 的 框架 ， 具 体 的 实现 方法 还 是 仁者 见 仁 的 。 


SPI 总 线 框架 对 这 两 类 设备 进行 管理 ， 具 体 的 框架 如 图 7-6 所 示 。 
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从 图 7-6 中 可 见 ，SPI 设备 主要 是 为 内 核 中 不 同 的 功能 模块 服务 的 ， 当 不 同 功能 模 
块 的 驱动 需要 使 用 SPI 设备 进 行 操作 时 ,通常 会 在 具体 的 管理 实体 中 舱 入 spi, device, 
实际 的 总 线 操作 通过 spi device 来 实现 。 图 中 右 侧 可 见 特殊 的 spidev, 这 是 对 应 用 开放 
的 接口 设备 ，SPI 通过 CS 信号 进行 设备 管理 ， 而 相应 的 CS 排列 主要 属于 板 级 信息 ， 所 
以 不 适合 像 了 C 总 线 一 样 将 总 线 控制 器 对 应 用 开放 (应 用 程序 操作 设备 需要 对 不 同 板子 
进行 修改 ) 。 将 CS 信息 对 应 用 屏 项 ， 只 开放 具体 的 设备 ， 这 就 是 spidev 的 作用 ， 应 用 
只 是 针对 具体 的 设备 进行 操作 ， 即 设备 的 应 用 层 驱 动 (驱动 在 用 户 态 执行 )， 要 在 应 用 
层 使 用 该 功能 需要 在 注册 设备 时 将 spi_board_info 中 的 modalias 设置 为 spidev， 这 样 就 可 
以 在 应 用 层 实现 相应 设备 的 驱动 。 通 常 的 SPI 驱动 都 是 在 内 核实 现 并 在 内 核 态 执行 的 ， 


所 以 就 不 对 spidev 进行 详细 的 分 析 。 














SPI 总 线 框架 整体 的 功能 就 是 这 样 ， 接 下 来 看 看 具体 各 部 分 的 实现 。 





2. 总 线 控制 器 相关 
SPI 总 线 框架 对 总 线 控制 厦 的 管理 主要 是 通过 i2c_adapter 来 实现 的 ， 其 详细 分 析 如 下 : 
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传输 字 


线 操 
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struct spi_master | 
// 设 备 模型 相关 
struct device dev; 
// 框 架 管 理 的 链表 


struct list_head list; 


























// 总 线 编号 ,通常 与 硬件 控制 器 编号 对 应 























s16 bus num; 

// $e iil ae DAE B) Fr eA 

ul6 num_chipselect; 
/控制 器 要 求 的 DMA 范围 

ul6 dma_alignment; 














/控制 器 特殊 的 属性 ,通常 与 信号 极 性 .相位 .CS 的 极 性 相关 


ul6 mode. bits; 























// 驱 动 的 限制 如 半 双 工 、 只 读 或 只 写 等 





























ul6 flags; 

// 相 关 的 锁 

spinlock_t bus_lock_spinlock; 

struct mutex bus_lock_mutex ; 

bool bus lock flag; 

// 该 接口 主要 用 于 激活 总 线 控制 器 与 特定 设备 的 总 线 连接 ,需要 对 传输 参数 做 匹配 
int ( * setup) (struct spi, device * spi); 

// 该 接口 用 于 总 线 事务 的 传输 

int ( * transfer) (struct spi, device * spi, struct spi message * mesg) ; 


// 当 某 个 连接 在 控制 器 上 的 设备 移 除 时 需要 进行 相关 操作 的 接口 . 
void ( * cleanup) (struct spi, device * spi); 


l; 











KF setup 接口 ， 框 架 为 设备 进行 操作 提供 了 统一 的 接口 spi_setup ， 其 中 会 对 信和 号 属性 、 


FK, 总 线 频率 等 进 和 人 了 匹配 和 设置 。 


这 里 所 有 的 接口 都 是 与 设备 总 线 控制 器 相关 的 ， 通 过 这 些 接口 设备 的 总 线 控制 器 实现 总 











作 。 
SPI 总 线 框架 为 总 线 控制 器 驱动 开发 提供 了 相关 的 接口 ， 具 体 如 下 : 





// 分 配 总 线 控制 器 管理 实体 

struct spi_master * spi_alloc_master(struct device * dev, unsigned size) ; 
/注册 加 入 系统 管理 
int spi register master(struct spi master * master) ; 


/注销 相关 总 线 控制 器 管理 实体 











void spi_unregister_master( struct spi_master * master) ; 
// 通 过 总 线 编号 获得 总 线 控制 器 管理 实体 


struct spi_master * spi_busnum_to_master(ul6 busnum) ; 








下 面 详细 看 看 spi_alloc_master 的 具体 实现 过 程 : 


struct spi master * spi_alloc_master(struct device * dev, unsigned size) 


| 


struct spi_master * master; 


if( ! dev) 
return NULL; 
// 分 配 spi. master 以 及 设备 指定 所 需要 的 空间 
master = kzalloc(size + sizeof * master, GFP_KERNEL) ; 
if( ! master) 
return NULL; 
// 设 备 模型 初始 化 
device_initialize( &master -> dev) ; 
// 指 定 为 spi. master, class 
master —> dev. class = &spi_master_class; 
master —> dev. parent = get_device( dev) ; 
// 将 为 设备 分 配 的 空间 (在 spi; master 之 后 ) 写 人 dev data 中 


spi_master_set_devdata( master, &master[ 1 | ) ; 





return master ; 


这 里 还 为 设备 分 配 了 所 需 的 空间 ， 设 备 不 需要 进行 相应 的 操作 ， 只 要 通过 spi_master_ 
get. devdata 来 获得 相应 的 指针 即 可 。 

spi register master 注册 了 总 线 控制 器 ， 就 相当 于 建立 了 总 线 ， 相 应 的 会 将 总 线 中 的 设备 
创建 并 注册 。 这 里 主要 通过 如 下 操作 完成 相应 功能 : 

















list_for_each_entry(bi, &board_list, list) 


spi_match_master_to_boardinfo( master, &bi -> board. info) ; 


这 里 是 实现 总 线 设备 发 现 相关 功能 ， 根 据 板 级 的 信息 注册 spi. device, 

总 线 的 主要 功能 (包括 总 线 传输 事务 、 总 线 设备 发 现 ) 就 都 在 代表 SPI 总 线 的 SPI 总 线 
控制 器 部 分 有 了 完整 的 支持 。 

3. 总 线 设 备 相关 

对 SPI 总 线 设 备 的 管理 ，SPI 总 线 框架 提供 了 spi device 来 完成 该 功能 ， 详 细 内 容 
如 下 : 
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struct spi_device | 


E 
从 相关 


// 设 备 模型 相关 

struct device dev; 

// 所 关联 的 总 线 控制 器 

struct spi_master * master; 
/设备 要 求 的 最 大 总 线 频率 

u32 max_speed_hz; 
// 所 用 的 片 选 信号 

u8 chip_select; 

// 信 号 的 模式 ,主要 是 相位 极 性 等 
u8 mode; 

// Y A& fei B 
u8 bits_per_word ; 

// 设 备 为 系统 提供 的 中 断 号 ,通常 是 GPIO 对 应 的 中 断 号 

int irq; 

// 总 线 控制 器 相关 的 状态 信息 和 数据 ,由 于 每 个 设备 的 信号 . 字 长 等 属性 不 同 
// 所 以 需要 保存 这 些 状态 ,以 便 驱 动 进行 总 线 传输 时 在 不 同 的 状态 间 切 换 . 


void * controller. state; 





















































void * controller data; 
// 用 于 与 SPI driver 绑 定 的 名 字 . 
char modalias[ SPI, NAME SIZE ] ; 











属性 来 看 ， 主 要 是 master 及 其 与 总 线 信 号 相关 的 属性 。 下 面 来 看 看 与 之 关联 


driver 的 详细 信息 : 


struct spi, driver | 


l; 





// 表 示 支 持 的 设备 
const struct spi_device_id * id_table; 


/标准 的 设备 模型 操作 ,用 于 设备 绑 定 的 初始 化 以 及 设备 移 除 的 资源 释放 















































int ( * probe) (struct spi, device * spi); 

int ( * remove) (struct spi, device * spi); 
/电源 管理 相关 接口 

void ( * shutdown) (struct spi, device * spi); 

int ( * suspend) (struct spi device * spi, pm, message t mesg) ; 
int ( * resume) (struct spi, device * spi) ; 

/设备 模型 接口 

struct device_driver driver; 


从 spi, driver 的 内 容 分 析 可 见 ， 其 主要 负责 总 线 相关 以 及 电源 管理 相关 的 操作 ， 操 作 接 








口中 并 不 涉及 实际 的 信息 传输 ， 可 以 说 该 驱动 同样 是 处 理 总 线 和 设备 模型 相关 的 事务 ， 并 不 











涉及 功能 的 事务 。 功 能 型 事务 涉及 操作 的 具体 内 容 是 在 功能 型 驱动 中 通过 SPI 的 接口 实现 
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的 。 而 功能 型 的 事务 需要 有 总 线 设备 的 信息 。 这 就 要 求 功 能 型 驱动 管理 实体 中 能 够 包含 spi_ 
device 的 信息 。 这 个 桥梁 是 与 SPI 总 线 事务 相关 的 ， 所 以 该 工作 自然 就 由 spi, driver 来 实现 ， 
具体 的 接口 就 是 probe， 这 样 各 种 实体 就 关联 起 来 。 以 ads7846_probe 接口 为 例 ，ads7846 是 
SPI 总 线 接口 的 触 屏 控 制 器 ， 在 功能 类 型 中 对 应 于 输入 设备 ， 相 应 的 spi_driver_ 的 probe 接口 
即 ads7846_probe 中 有 如 下 代码 : 








static int __devinit ads7846_probe( struct spi_device * spi) 
| 
struct ads7846 * ts; 
struct ads7846_packet * packet; 
struct input_dev * input_dev; 
struct ads7846_platform_data * pdata = spi -> dev. platform, data; 
unsigned long irg_flags ; 


int err; 


/ * don t exceed max specified sample rate * / 
if( spi -> max speed hz > (125000 * SAMPLE_BITS) ) | 
dev. dbg( &spi -> dev, "f(sample) 96d KHz? \n", 
(spi - > max, speed hz/SAMPLE. BITS)/1000) ; 
return — EINVAL; 
} 
spi —> bits per word =8; 
spi -> mode = SPI MODE 0; 
err = spi_setup(spi) ; 
if( err <0) 


return err; 


ts = kzalloc( sizeof( struct ads7846) , GFP. KERNEL) ; 
packet = kzalloc( sizeof( struct ads7846. packet) , GFP. KERNEL) ; 
input, dev = input, allocate device( ) ; 
if( ! ts || ! packet || ! input, dev) | 
err  - ENOMEM ; 


goto err free mem; 


dev. set, drvdata( &spi -> dev, ts); 


ts —» packet = packet; 
ts —» pdata = pdata; 

ts 一 > spi = spl; 

ts —» input = input, dev; 


ts —» vref mv = pdata —» vref mv; 
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| 


ts —> swap_xy = pdata —> swap_xy; 


从 中 可 见 ，spi device, fth BE $$ e FRE PREIS input device 建立 了 关联 ， 这 样 从 功能 型 
设备 到 总 线 设备 就 形成 了 一 个 整体 ， 可 以 进行 完整 的 操作 。 只 有 总 线 设 备 与 功能 管理 实体 关 
联 后 才能 完成 功能 性 的 工作 。 








无 论 spi. device 还 是 spi_driver 都 属于 SPI 总 线 框架 管理 的 运行 时 实体 ， 而 SPI 总 线 设 备 























通常 是 直接 焊接 在 板子 上 面 ， 这 些 固定 的 信息 同样 需要 进行 表示 ， 在 创建 动态 管理 的 设备 实 











体 时 需要 这 些 信息 。 在 SPI 总 线 框架 中 相应 的 实体 是 spi_poard_info ， 内 容 如 下 : 


struct spi, board info | 


l; 


/匹配 的 名 字 

char modalias[ SPI, NAME SIZE ] ; 

// 设 备 特殊 数据 

const void * platform_data; 

void * controller_data; 

// 设 备 连接 的 中 断 号 ,通常 GPIO 对 应 的 中 断 
int irq; 
// 设 备 能 接受 的 总 线 频率 
u32 max_speed_hz; 
// 设 备 所 在 总 线 编号 

ul6 bus_num; 
/设备 所 在 总 线 的 片 选 信号 
ul6 chip. select ; 

// 信 号 的 模式 


u8 mode; 
































其 中 的 主要 信息 是 与 总 线 信号 相关 的 属性 。 


对 SPI 总 





线 设备 的 创建 ， 框 架 提 供 了 相应 的 函数 接口 ， 具 体 如 下 : 





struct spi device * spi new, device( struct spi, master * master, struct spi, board, info * chip) 


从 中 可 见 ， 要 创建 总 线 设 备 需 要 spi master 和 spi_board_info， 对 于 特定 总 线 设 备 有 spi_ 
board info 信息 ， 这 就 需要 明确 与 spi master 关联 。 

创建 总 线 设备 有 两 种 方法 : 

方法 一 是 通过 struct spi, master. * spi_busnum_to_master(ul6 busnum) ; 来 获得 指定 的 spi 
_master， 人 然后 调用 spi_new_device 来 创建 总 线 设备 。 

方法 二 是 早期 的 初始 化 阶段 调用 spi_register_board_info( struct spi_board_info const * info, 
unsigned n) ; 函数 注册 某 个 SPI 总 线 上 的 所 有 设备 信息 ， 在 总 线 控制 器 spi_master 会 在 注册 时 
遍历 这 些 信 息 为 总 线 上 的 设备 创建 spi_device。 

方法 一 主要 用 于 总 线 设 备 信息 初始 化 晚 于 spi, master 初始 化 的 情况 ， 如 使 用 SPI 总 线 的 
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VAL2 子 设备 ; 而 方法 二 则 用 于 较 早 初始 化 的 情况 。 

4. 总 线 传输 接口 

总 线 传输 是 完成 功能 型 事务 的 基础 。SPI 总 线 传输 是 由 spi_message 和 spi_transfer 共同 进 
行 管理 的 ， 下 面 来 看 一 下 详细 内 容 : 








struct spi_message | 


//spi_transfer 的 链表 


struct list_head transfers ; 

// 关 联 的 SPI 总 线 设备 

struct spi_device * spi; 

// 是 否 已 经 进行 了 DMA 映射 
unsigned is_dma_mapped:1 ; 


/ * completion is reported through a callback */ 


// 完 成 完整 传输 后 报告 的 回调 






































void ( * complete) (void * context) ; 
人/ 回调 的 参数 ,通常 是 completion 

void * context; 

// 实 际 成 功 传输 的 长 度 以 byte 为 单位 

unsigned actual_length; 

// 传 输 状 态 ,0 为 成 功 ,负数 为 错误 值 

int status ; 

// 总 线 控制 器 驱动 使 用 , 主要 用 于 总 线 传 输 队 列 
struct list_head queue; 

void * state; 


E 


struct spi_transfer | 


// 数 据 空间 

const void * tx_buf; 
void * rx_buf; 
// 数 据 长 度 


unsigned len; 
// 如 果 使 用 DMA ,相关 的 数据 地 址 信息 


dma_addr_t tx_dma; 











dma_addr_t rx_dma; 

// transfer 完成 是 否 需要 CS 变化 
unsigned cs change:l; 

ACE 

u8 bits_per_word ; 


// 从 数据 操作 完 到 CS 变化 的 延 时 设置 
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ul6 delay_usecs ; 
// 总 线 频率 

u32 speed_hz; 

/人 /传输 列表 

struct list head transfer. list ; 


E 


可 见 SPI 总 线 设 备 的 总 线 传输 是 以 spi transfer 为 单位 的 ， 可 以 进行 批 处 理 ， 将 一 次 批 处 
理 所 有 的 spi_transfer， 并 形成 链表 通过 spi_message 进行 管理 。 而 spi_message 中 会 与 具体 的 
spi_device 关联 ， 这 样 某 个 SPI 总 线 设备 的 总 线 传输 需要 的 所 有 信息 就 可 以 通过 spi_message 
进行 管理 。 
通常 设备 进行 SPI 传输 的 操作 流程 如 下 : 




















// 初 始 化 spi_message 

spi_message_init(m) ; 

// 设 置 传输 transfer 参数 

packet —» read, y. emd[ 0] = READ_Y (vref) ; 
[1] 20; 

packet —» read. y. cemd[ 2] 20; 

x —» tx, buf = &packet —» read. y. cemd[ 0] ; 























packet —» read, y. emd 


x —» x buf = &packet —> tc. y_buf[ 0] ; 
x -»len 23; 
// 加 入 链表 


spi_message_add_tail(x, m) ; 








功能 型 驱动 可 以 根据 自身 的 需要 设置 spi transfer, 读 写 操作 信息 都 设置 在 一 起 ， 然 后 通 
过 spi message add tail 加 入 spi message 链表 中 ; 在 spi message 准备 好 之 后 ， 就 可 以 通过 
spi sync 进行 实际 的 传输 操作 。 具 体 如 下 : 











error = spi_sync(ts —>spi, m); 


这 样 设备 就 同步 等 待 操作 完成 ， 具 体 的 实现 是 通过 _spi_sync 来 完成 的 ， 细 节 如 下 : 





static int __spi_sync( struct spi device * spi, struct spi message * message, int bus locked) 
| 

// 声 明 completion 

DECLARE_COMPLETION_ONSTACK( done) ; 

int status; 

// 获 得 总 线 控制 需 

struct spi_master * master = spi 一 > master; 

/人 /同步 操作 回调 和 参数 


message — > complete = spi_complete ; 
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message — > context 2 &done; 


/总 线 独 享 控制 
if( ! bus, locked ) 
mutex, lock ( &master -> bus lock mutex) ; 
// 异 步 锁 操 作 , 实 际 调用 的 总 线 控制 器 的 transfer 操作 直接 返回 


status = spi_async_locked( spi, message) ; 


if( ! bus, locked ) 
mutex, unlock ( &master -> bus. lock mutex) ; 
// 等 待 总 线 控制 器 操作 完成 


if( status ==0) | 





wait, for completion( &done) ; 
status = message 一 > status; 

} 

message — > context = NULL; 


return status; 


| 





可 见 主 要 操作 是 由 总 线 控制 絮 驱 动 完 成 的 ， 而 在 总 线 框 架 层 则 是 等 待 completion 同步 操 
作 完 成 后 返回 ， 这 样 就 可 保证 整个 传输 的 操作 是 以 同步 方式 实现 的 。 


7.2.3 TI 芯片 SPI 总 线 驱动 相关 实现 详解 


DM 3730 的 SPI 控制 器 框架 如 图 7-7 所 示 。 图 7-7 引 自 《DM 3730 芯片 手册 》 中 第 
2998 页 的 框图 。 

从 图 7-7 可 见 ， 作 为 SPI 控制 器 既 可 以 做 master 也 可 以 做 slave, Æ Linux 内 核 中 主要 是 
实现 master 的 功能 ;FIFO 用 于 进行 数据 缓冲 ， 可 以 通过 处 理 器 读 写 ， 也 可 以 通过 DMA ix 
写 ， 由 于 SPL 总 线 速度 要 高 ， 所 以 当 进行 大 量 数据 读 写 时 需要 使 用 DMA 进行 操作 。 另 外 不 
同 的 channel 代表 不 同 CS 控制 的 设备 ， 这 样 可 以 对 设备 进行 单独 的 操作 。 

对 于 DM 3730 SPI 的 驱动 部 分 ， 主 要 分 析 相 关 的 初始 化 和 总 线 传输 的 操作 。 

1. 初始 化 

先 来 看 看 初始 化 部 分 ，SPI BZ PE Till ae VED SoC HAAS PE til at, TH DEY SK oh ERE YE Oy 
platform driver 存在 ， 在 系统 初始 化 时 会 注册 相应 的 platform device (通过 omap_init_mespi 来 
实现 ) ， 而 在 platform driver 的 probe 函数 中 会 根据 platform device 的 信息 进行 初始 化 ， 这 个 初 
始 化 十 分 重要 。 下 面 详细 了 解 其 内 容 : 



































static int __init omap2 mespi, probe( struct platform_device * pdev) 


| 


struct spi_master * master; 
struct omap2  mespi * mespi; 
Struct resource * rs 
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图 7-7 DM 3730 SPI 总 线 控制 器 框架 
int status =0, i; 
const u8 * rxdma, id, * txdma, id; 
unsigned num chipselect ; 





// 根 据 SPI 控制 器 的 编号 设置 DMA request 信号 的 ID ,以 及 拥有 的 CS 信号 数目 
switch( pdev —> id) | 





case |: 
rxdma, id = spil_rxdma_id; 
txdma, id = spil_txdma_id; 
num chipselect 24; 


break ; 
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case 2; 
rxdma_id = spi2_rxdma_id; 
txdma_id = spi2_txdma_id; 
num_chipselect 22; 


break ; 


default; 
return — EINVAL; 
| 
/分 配 总 线 控制 器 管理 实体 ,并 为 设备 独立 管理 实体 分 配 空 间 
master = spi_alloc_master( &pdev -> dev, sizeof * mcspi) ; 
if( master == NULL) | 
dev. dbg( &pdev -> dev, "master allocation failed Wn" ) ; 
return - ENOMEM ; 


/ * the spi -> mode bits understood by this driver; * / 
/ CELERE tll aie SCH a PE 
master —» mode. bits = SPI_CPOL | SPI_CPHA | SPI. CS HIGH; 
/设置 总 线 编号 
if( pdev -> id! = -1) 

master — > bus num = pdev -> id; 
// SPI jM Td PRE Be O WARE 


master — > setup = omap2. mcspi. setup; 











master — > transfer = omap2 mcspi transfer; 
master 一 > cleanup 三 omap2 mcespi cleanup; 
master —» num. chipselect = num. chipselect ; 
// 设 置 设备 特殊 信息 
dev_set_drvdata( &pdev -> dev, master) ; 

/与 设备 独立 的 总 线 控制 器 管理 实体 进行 关联 


mcspi = spi_master_get_devdata( master) ; 














mcspl — > master = master; 


// 检 查 寄存 器 空间 ,并 向 系统 申请 相关 空间 
r = platform_get_resource( pdev, IORESOURCE MEM, 0) ; 
if(r == NULL) | 
status = — ENODEV ; 
goto errl ; 
| 
if( | request_mem_region(r—> start, (r -> end — r—>start) + 1, 
dev. name( &pdev —> dev) ) ) | 
status = — EBUSY; 
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goto errl ; 


/进行 寄存 器 空间 映射 操作 


Imcspi —> phys =T 一 > start; 





mespi —> base = ioremap(r —» start, r -> end - r—>start + 1); 
if( ! mespi —» base) | 
dev. dbg( &pdev -> dev, "can t ioremap MCSPI\n" ) ; 
status = - ENOMEM; 
goto errl aa ; 
} 
// 初 始 化 work 用 于 对 SPI 传输 进行 操作 
INIT WORK( &mespi -> work, omap2_mespi_work ) ; 





spin, lock, init( &mespi -> lock) ; 

// 设 备 驱 动 对 于 传输 操作 维护 的 队列 

INIT. LIST HEAD( &mespi —» msg queue) ; 

INIT. LIST HEAD( &omap2_mespi_ctx| master —» bus num - 1]. cs); 





/WISEROS RUE 
mespi —> ick = elk, get( &pdev -> dev, "ick" ) ; 
if(IS_ERR( mespi -> ick) ) | 
dev. dbg( &pdev -> dev, "can t get mespi_ick\n" ) ; 
status = PTR, ERR( mespi - > ick) ; 
goto errla; 
} 
mespi — > fck = clk_get( &pdev -> dev, "fck" ) ; 
if( IS. ERR( mespi —> fck) ) | 
dev. dbg( &pdev -> dev, "cad t get mespi fckWn" ) ; 
status = PTR, ERR( mespi -> fck) ; 
goto eri; 
} 
/为 控制 器 的 DMA channel 管理 申请 管理 实体 的 空间 ,并 初始 化 
mespi — > dma_channels = kcalloc( master -> num_chipselect ， 
sizeof( struct omap2_mespi_dma) , GFP_KERNEL) ; 














if( mespi -> dma_channels == NULL) 


goto err3 ; 


for(i =0; i < num chipselect; i++ ) | 
mespi —» dma, channels[ i]. dma, rx. channel = -1; 
mespi —» dma, channels[ i]. dma, rx. sync. dev = rxdma  id[ i]; 


mespi —» dma, channels[ i]. dma, tx channel = -1; 
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mcspi — > dma_channels{ i ]. dma, tx. sync. dev = txdma, id[ i] ; 
} 
// 控 制 器 reset 保证 状态 确定 


if( omap2, mespi, reset( mespi) <0) 





goto err4; 
// fi] SPI 总 线 框架 注册 控制 器 实体 


status = spi_register_master( master) ; 





if(status <0) 


goto err4; 


return status ; 


| 








因为 SPI 对 吞吐 量 要 求 比较 高 ， wok IER, 而 系统 通常 有 
多 个 SPI 总 线 控制 器 ， 继 续 提 高 吞吐 量 的 方法 就 是 建立 work queue， 这 些 是 在 omap2_mespi_ 
init 初始 化 中 进行 的 n 细节 如 下 : 


























static int __init omap2_mespi_init( void) 


| 





// 创 建 单 内 核 线程 执行 的 work queue 
omap2_mcspi_wq = create_singlethread_workqueue( 
omap2_mcespi_driver. driver. name) ; 
if( omap2_mespi_wq == NULL) 
return — 1; 
// 注 册 platform driver 


return platform_driver_probe( &omap2_mcspi_driver, omap2_mcspi_probe) ; 


| 


可 见 ， 为 了 SPL 总 线 传输 单独 创建 了 work queue, 以 保证 整体 的 性 能 

2. 总线 传输 接口 

对 于 SPI 总 线 的 传输 ， 由 于 性 能 的 需求 ， 主 要 使 用 DMA 进行 相关 的 操作 。 而 在 SPI 总 
线 框架 ， 主 要 提供 了 两 个 传输 接口 ， 分 别 是 spi master 中 的 setup 和 transfer。 下 面 看 看 DM 
3730 的 具体 实现 过 程 。 

先 来 看 看 setup 接口 setup 接口 主要 是 创建 传输 需要 的 资源 ， 如 申请 DMA 等 。 











static int omap2_mcspi_setup( struct spi, device * spi) 


| 


int ret; 
struct omap2_mespi * mespi; 
struct omap2_mcspi_dma * mcespi_dma; 


struct omap2_mcspi_cs — * cs = spi — > controller state ; 
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// 检 查 字 长 是 否 是 硬件 支持 的 
if(spi—>bits_per word <4 || spi—> bits_per_word > 32) | 
dev_dbg( &spi —» dev, "setup: unsupported %d bit words\n" , 
spi —» bits, per. word) ; 
return — EINVAL; 
| 
// 获 得 设备 的 控制 器 管理 实体 


mcspi = spi_master_get_devdata( spi —» master) ; 








mespi_dma = &mespi —» dma_channels[ spi -> chip. select | ; 








// WR AC AIT 6 8 EET tll d HOS BS DE A fr J 





if( 1 es) | 
cs = kzalloc(sizeof * cs, GFP. KERNEL) ; 
if( ! es) 


return - ENOMEM ; 
/记录 对 应 CS 的 寄存 器 地 址 
cs —> base = mespi —» base + spi —» chip. select * 0x14; 
cs —» phys = mespi -> phys + spi -» chip. select * 0x14; 
/初始 channel f] 25 7F di B (EL, Ft te EAD T TRTEZT ESF ELS FR URTT BUR: 
es 一 > chconfO 2 0; 


























spi —> controller state = cs; 
/* Link this to context save list * / 
// 加 入 驱动 中 ,进行 电源 管理 相关 的 操作 


list_add_tail( &cs -> node, &omap2_mcspi_ctx[ mespi —» master —» bus num - 1]. cs) ; 




















// 如 果 没 有 则 申请 DMA 


if(mespi_dma -> dma_rx_channel == -1 





| | mespi_dma —» dma tx channel == - 1) | 
/* TI81XX has EDMA and not SDMA, hence overriding SDMA usage * / 
if( | cpu_is_ti81xx() ) 
ret = omap2_mespi_request_dma( spi) ; 
else 
ret 20; 
if( ret <0) 


return ret ; 


// 对 控制 顺 进 行 操 作 先 要 获得 clock 
if( omap2_mespi_enable_clocks(mespi) ) 
return - ENODEV ; 
/下 面 要 根据 信号 属性 进行 基本 的 寄存 器 设置 
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ret = omap2_mespi_setup_transfer(spi, NULL) ; 


omap2_mespi_disable_clocks( mespi) ; 


return ret; 





这 里 主要 是 对 于 与 控制 器 相关 的 设备 状态 的 初始 化 、DMA 的 申请 ， 以 及 根据 相应 信和 号 
属性 来 初始 化 相关 寄存 器 。 
接 下 来 看 看 transfer 接口 的 实现 过 程 : 





static int omap2_mespi_transfer( struct spi, device * spi, struct spi message * m) 


| 


struct omap2 mespi 





* mespi; 


unsigned long flags; 


struct spi. transfer xt; 
// 初 始 化 传输 状态 
m —>actual_length 20; 


m —» status 20; 


/ * reject invalid messages 


and transfers * / 








/链表 是 空 或 者 没有 设置 




















回调 是 无 效 的 传输 ,返回 错误 





if( list_empty( &m ->transfers) || ! m —» complete) 


return — EINVAL; 


// 对 每 个 transfer 的 属性 进行 检查 和 设置 


list_for_each_entry(t, &m —> transfers, transfer. list) | 





const void * ix buf =t -»tx buf; 


void * rx buf =t -> rx. buf; 


unsigned len =t —> len; 

// 检 查 transfer 参数 是 否 支持 

if( t -> speed hz > OMAP2 MCSPI MAX FREQ 
|| (len &&! (rx buf || tx buf)) 
|| (t -> bits per word && 


( t—-» bits per word «4 || t —» bits per word »32))) | 
dev, dbg( &spi -> dev, "transfer; 96d Hz, 96d 96s96s, 96 d bpw\n" , 


t-»speed hz, len, tx buf ? "tx" , "", 


rx buf ? "rx" ; "", t—> bits per word) ; 


return — EINVAL; 


| 


if(t -> speed hz && t —» speed. hz < OMAP2, MCSPI. MAX, FREQ/ (1 ««16)) | 


dev, dbg( &spi -> dev, "96 d Hz max exceeds % d\n", 


t-»speed hz, 
OMAP2, MCSPI, MAX FREQ/(1 ««16)) ; 
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return — EINVAL; 


if( m —» is_dma_mapped || len < DMA_MIN_BYTES) 
continue ; 

// 使 用 流 式 DMA 映射 来 分 配 DMA 操作 的 空间 

if(tx buf! = NULL) | 





t —>tx_dma = dma, map. single( &spi -> dev, (void * ) tx buf, 
len, DMA. TO. DEVICE) ; 
if( dma, mapping. error( &spi -> dev, t —» tx dma) ) | 
dev. dbg( &spi -> dev, "dma 96 cX 96d bytes error\n" , 
'T , len); 
return — EINVAL; 


} 
if( rx. buf! = NULL) | 
t -» rx, dma = dma, map. single( &spi -> dev, rx buf, 
t-»len, DMA. FROM. DEVICE) ; 
if( dma, mapping. error( &spi -> dev, t -> rx dma) ) | 
dev. dbg( &spi -> dev, "dma 96 cX 96d bytes error\n" , 
' R , len); 
if(tx. buf! = NULL) 
dma, unmap. single( NULL, t-> tx dma, 
len, DMA, TO. DEVICE) ; 
return — EINVAL; 


} 

// 获 得 控制 器 管理 实体 

mespi = spi_master_get_devdata( spi -> master) ; 

// 获 得 控制 器 的 锁 

spin_lock_irqsave(&mcspi -> lock, flags) ; 

// 将 传输 信息 加 入 驱动 的 队列 ,并 唤醒 Work Queue 执行 相应 的 work 


list_add_tail( &m -> queue, &mespi -> msg_queue); 








queue, work ( omap2_mcspi_wq, &moespi -> work) ; 


spin, unlock, irqrestore( &mespi —> lock, flags) ; 
return 0; 


主要 的 工作 仍 在 设置 上 ， 这 里 是 为 DMA 分 配 空间 建立 映射 ， 并 唤醒 work queue 执行 实 
际 的 操作 。work 在 初始 化 时 已 经 设置 了 相应 的 操作 omap2_mcspi_work， 这 是 执行 实际 的 总 
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线 传输 的 操作 。 下 面 看 看 实现 细 方 : 


static void omap2_mespi_work( struct work struct * work) 


| 


struct omap2 mespi 
/找到 控制 器 管理 信息 


mespi = container of( work, struct omap2, mespi, work) ; 








/操作 中 要 获得 锁 
spin lock irq( &mespi —> lock) ; 
/使 能 控制 器 时 钟 


if( omap2_mespi_enable_clocks(mespi) ) 








goto out ; 
/遍历 控制 器 的 操作 链表 ,进行 所 有 的 操作 


while( | list_empty( &mcspi -> msg. queue) ) | 





struct spl. message 


struct spi, device 


struct spi, transfer 


int 


struct omap2 mcspi. cs 


* mespi; 


*m; 


* spl; 
* t= NULL; 
cs, active 20; 


* CS; 


struct omap2. mcspi. device, config * cd; 


int 
int 


u32 


// 获 得 一 个 总 线 传输 信息 


m = container_of( mcspi —» msg queue. next, struct spi message, 


queue) ; 


// 将 其 移出 队列 
list_del_init( &m —> queue) ; 
// 为 避免 长 时 间 占 用 锁 , 这 里 释放 


spin unlock irq( &mespi —> lock) ; 


spi =m —» spi; 


cs = spi 一 > controller. state; 


cd = spi —> controller. data; 
// 总 线 控制 器 设置 channel X enable 
omap2_mcspi_set_enable( spi, 1); 


// 对 所 有 的 transfer 进行 操作 


list_for_each_entry(t, &m —» transfers, transfer. list) | 


if( t -» tx. buf == NULL && t -> rx buf == NULL && t —» len) | 


status = — EINVAL; 
break ; 


par_override =0; 
status =0; 


chconf ; 
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if( par. override || t —» speed. hz || t —» bits, per. word) | 
par. override 21; 
status = omap2. mespi. setup. transfer( spi, t) ; 
if( status <0) 
break ; 
if( ! t -> speed hz &&!t —» bits per word) 
par. override 20; 
| 
// 先 要 设置 CS 信号 
if( ! es, active) | 
omap2. mespi, force cs(spi, 1) ; 


cs active 21; 


// 内 存 缓存 了 channel 控制 寄存 器 的 值 
chconf = mespi_cached_chconf0 ( spi ) ; 
chconf & = ~ OMAP2 MCSPI CHCONF TRM, MASK ; 
chconf & = ~ OMAP2 MCSPI CHCONF TURBO; 
// 根 据 传输 特性 进行 寄存 器 设置 
if( t —> ix. buf == NULL) 
chconf | = OMAP2 MCSPI CHCONF TRM RX ONLY; 
else if(t -> rx buf == NULL) 
chconf | = OMAP2 MCSPI CHCONF TRM TX ONLY; 














if( cd && cd —» turbo. mode && t —» tx buf == NULL) | 
/ * Turbo mode is for more than one word * / 
if(t -» len > ( (cs -> word len + 7) >>3)) 
chconf | = OMAP2. MCSPI, CHCONF. TURBO; 
| 
// 写 channel 控制 寄存 需 
mcespi_write_chconf0( spi, chconf) ; 


if(t —> len) | 


unsigned count; 


/* RX ONLY mode needs dummy data in TX reg */ 
if(t -> tx buf == NULL) 
. raw, writel(0, cs —» base + OMAP2. MCSPI. TXO) ; 
// 根 据 需 要 进行 DMA 传输 或 者 处 理 器 直接 进行 操作 
if( m —» is_dma_mapped || t-> len >= DMA, MIN BYTES) 
count = omap2  mespi. txrx. dma( spi, t); 


else 


count = omap2_mcespi_txrx_pio(spi, t); 
// 对 操作 数目 状态 进行 更 新 


m—>actual_length + = count; 








if( count! = t —> len ) f 
status = — EIO; 
break; 


} 
// 一 次 transfer 结束 ,如 果 需 要 等 待 则 等 待 一 定时 间 
if(t—> delay_usecs) 

















udelay( t -> delay, usecs) ; 


/ * ignore the "leave it on after last xfer" hint * / 
// 如 果 必 要 进行 CS 操作 
if(t —> es. change) | 

omap2. mespi, force es(spi, 0) ; 

// 记 录 CS 信号 状态 


cs_active =0; 


/* Restore defaults if they were overriden */ 
if( par. override) | 
par. override 20; 
status = omap2, mespi, setup. transfer( spi, NULL) ; 
} 
if( cs. active) 
omap2 . mespi, force, es( spi, 0) ; 
// KB TE Wilde ix E channel Jy disable 


omap2, mespi, set, enable(spi, 0) ; 





/传输 结束 ,设置 状态 并 完成 总 线 框架 层 的 同步 操作 . 


m 一 > status = status ; 





m —» complete( m —> context) ; 


spin. lock, irq( &mespi -> lock) ; 


/关闭 总 线 控制 器 相关 clock 


omap2_mespi_disable_clocks( mespi ) ; 
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spin unlock irq( &mespi -> lock) ; 


| 








可 见 DM 3730 总 线 控制 侨 的 传输 操作 考虑 了 性 能 以 及 功 耗 的 需求 ， 通 过 单独 的 内 核 执 
行 实体 进行 操作 ， 并 考虑 到 效率 的 需求 ， 根 据 传输 数据 量 进行 DMA 或 者 处 理 器 直接 操作 的 
方式 进行 实际 的 IO 操作 ， 实 际 的 操作 参见 相关 代码 。 

到 这 里 整个 传输 从 设置 到 实际 操作 就 介绍 完了 。 
7.2.4 SPI 总 线 驱 动 电源 管理 相关 说 明 


关于 电源 管理 ， 先 看 看 SPI 总 线 层面 提供 的 功能 : 











struct bus_type spi_bus_type = | 


. name SS pe 

. dev_attrs = spi_dev_attrs , 

. match = spi match device, 
. uevent = spi uevent, 


. suspend = spi. suspend, 
. resume -spi resume, 


| 





可 见 只 提供 了 SLM 的 相关 功能 ， 下 面 以 suspend 为 例 看 看 具体 的 实现 过 程 : 


static int spi suspend( struct device * dev, pm, message t message) 
int value 20; 


struct spi, driver * drv = to, spi. driver( dev —> driver) ; 


/ * suspend will stop irqs and dma; no more i/o */ 
if(drv) | 
if( drv -> suspend ) 
value = drv -> suspend( to. spi. device( dev) , message) ; 
else 
dev. dbg(dev, "... can t suspend n" ) ; 
} 


return value; 


| 











从 代码 中 可 见 ， 主 要 的 操作 是 通过 总 线 设备 的 驱动 来 完成 的 ， 其 中 通常 为 关闭 资源 的 








总 线 层面 是 针对 总 线 设备 进行 的 操作 ， 再 来 看 看 总 线 控制 器 相关 的 电源 管理 功能 。DM 
3730 SPI ZR HE Har AY runtime 电源 管理 功能 集中 在 传输 中 的 操作 ， 由 前 面 分 析 的 代码 中 可 
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知 ， 主 要 通过 omap2_mcespi_disable_clocks, omap2_mcspi_enable_clocks 和 omap2_mcspi_set_ 
enable 来 实现 模块 时 钟 、 模 块 开关 等 电源 管理 相关 的 操作 。 其 他 的 电源 管理 功能 则 由 omap2 
_mespi_pm_ops 来 提供 ， 具 体内 容 如 下 : 





static const struct dev. pm, ops omap2_mcspi_pm_ops = | 


. resume = omap2. mcspi, resume , 


l; 


为 什么 没有 suspend 操作 呢 ? 相应 的 suspend 操作 是 在 platform bus 的 suspend 接口 中 实 
现 的 ，SPI 总 线 控制 器 也 是 使 用 统一 的 操作 接口 。 在 从 低 功 耗 状 态 进 行 恢 复 的 时 候 SPI 总 线 
fa til ARS CS BE active 状态 ， 所 以 这 里 需要 特殊 的 操作 。 下 面 来 看 看 具体 实现 过 程 ， 





static int omap2. mespi, resume( struct device * dev) 
| 
struct spi_master * master = dev_get_drvdata( dev) ; 
struct omap2_mcspi * mespi = spi_master_get_devdata( master) ; 
struct omap2 mcespi cs * cs; 
// 进 行 操作 需要 使 能 clock 
omap2_mcspi_enable_clocks( mespi) ; 
// 对 所 有 连接 外 设 的 channel 控制 器 进行 设置 
list_for_each_entry( cs, &omap2_mcspi_ctx{ master -> bus num - 1]. es, 
node) | 
// 检 查 之 前 的 CS 状态 是 否 为 deactive 
if( (es -> cheonfü & OMAP2 MCSPI CHCONF FORCE) ==0) | 
// 进 行 设置 ,保证 为 deactive 状态 
MOD REG. BIT(cs -> chconf0 , OMAP2 MCSPI CHCONF FORCE, 1); 
. raw. writel( cs —» chconfü, cs -> base + OMAP2 MCSPI. CHCONFO) ; 
MOD REG. BIT(cs -> chconf0 , OMAP2 MCSPI CHCONF FORCE, 0); 
. raw. writel( cs —» chconf0, cs -> base + OMAP2 MCSPI. CHCONTFO) ; 








| 
// 关 闭 相关 时 钟 
omap2_mcspi_disable_clocks( mespi) ; 


return 0; 


| 
可 见 电 源 管理 相关 的 操作 也 会 涉及 功能 部 分 。 这 样 电源 管理 部 分 的 功能 就 完整 了 。 


7.3 多 媒体 卡 (MMC) 





7.3.1 MMC 需求 





MMC (HI multimedia card) 已 经 成 为 做 入 式 存储 设备 的 最 重要 的 连接 标准 。 它 于 1997 
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年 由 西门 子 与 SanDisk 共同 开发 ， 技 术 基 于 NAND 技术 ， 随 后 又 有 不 同 的 发 展 ， 现 如 今 已 经 
JÉ MMC, SD, eMMC, SDIO 等 不 同 的 形式 ， 而 连接 的 设备 也 是 多 种 多 样 的 ， 从 MMC 
Card, SD Card, microSD Card 等 存储 设备 ， 到 SDIO WLAN, SDIO GPS 等 设备 。 总 之 设备 形 
态 以 存储 设备 为 主 ， 相 应 的 SDIO 总 线 可 以 支持 不 同 功 能 的 设备 。 

MMC 的 架构 如 图 7-8 所 示 。 图 7-8 引 自 《MMC 规范 》。 
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7-8 MMC 架构 图 


从 图 7-8 可 见 ，MMC 连接 除了 CLK 和 VDD 之 外 还 有 CMD 和 DAT 信和 号， 其 中 CMD 信 
号 用 于 命令 交互 ， 而 DAT 信和 号 用 于 数据 交互 ，DAT 信号 可 以 有 多 个 。MMC 内 部 会 有 一 些 寄 
存 器 ， 这 些 寄存 器 记录 了 MMC 的 能 力 等 属性 ， 可 用 于 与 总 线 控制 器 协商 。 需 要 根据 这 些 控 
制 器 的 属性 值 正确 地 操作 MMC 设备 。 

MMC 的 信号 传输 特点 如 图 7-9 所 示 。 图 7-9 引 自 《DM 3730 芯片 手册 》 中 第 3384 页 
框图 。 
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图 7-9 MMC 信和 号 传输 特点 
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图 7-9 以 单一 的 读 操作 为 例 ， 可 见 MMC 的 信号 主要 通过 CMD 传送 命令 ， 并 且 需 要 响 
， 通 过 DAT 信和 号 传送 数据 。 为 了 能 正确 地 识别 MMC 设备 ， 并 正确 地 传输 数据 ，MMC 规 
范 规定 了 不 同 的 模式 及 命令 用 于 不 同 的 功能 ， 通 过 命令 可 以 在 不 同 的 状态 转换 。 这 些 都 属于 
规范 中 状态 及 状态 转换 的 内 容 ， 能 正确 地 支持 。 

MMC 总 线 可 以 连接 不 同 协议 标准 的 设备 ， 如 MMC, SD, 、SDIO， 这 些 都 需要 在 框架 中 
进行 支持 。 另 外 由 于 MMC 连接 的 设备 可 能 会 以 卡 的 形式 存在 ， 这 就 需要 能 够 支持 对 设备 插 
入 的 检测 ， 在 系统 级 别 也 需要 能 够 对 设备 插 拔 进行 支持 。 

总 体 上 来 说 ，MMC 总 线 驱动 的 需求 就 是 要 能 实现 总 线 的 各 种 功能 ， 并 且 满 足 总 线 的 各 


7.3.2 MMC 框架 解析 








于 






































1. 总 线 相关 以 及 核心 框架 
MMC 总 线 设 备 相 对 于 PC 和 SPI 总 线 要 复杂 ， 但 是 总 线 框架 的 思路 是 一 致 的 。 首先 来 
看 看 MMC 子 系统 的 初始 化 mme. init; 








static int __init mmc_init( void) 
int ret; 
// 创 建 work queue 


workqueue = create_singlethread_workqueue( " kmmed" ) ; 





if( ! workqueue ) 
return - ENOMEM ; 
// 注 册 mme bus 
ret = mme, register bus( ) ; 
if( ret) 
goto destroy. workqueue; 
// 注 册 mme host class 
ret = mme, register host class( ) ; 
if( ret) 
goto unregister bus; 
// 注 册 sdio bus 
ret = sdio_register_bus( ) ; 
if( ret) 


goto unregister host class; 


return 0; 
| 
从 分 析 可 见 ， 注 册 了 两 个 bus (分 别 是 mme bus 和 sdio bus) 和 一 个 class (mme host 
class) ， 这 里 有 两 种 类 型 的 bus 是 由 于 MMC 连接 还 需要 支持 SDIO 总 线 类 型 ， 而 在 MMC 框 


架 中 就 需要 实现 SDIO 总 线 的 功能 ， 其 中 SDIO 总 线 建立 在 MMC 总 线 的 基础 上 ， 所 以 需要 注 
639 








册 两 种 bus。 而 注册 一 个 class 的 原因 ， 与 SPI 设备 管理 部 分 的 实现 是 相同 的 ， 


免 总 线 控制 器 的 设备 进行 总 线 相关 的 操作 。 
接 下 来 看 看 两 个 总 线 的 信息 ， 
static struct bus. type mme, bus type = | 

. name ="mmc", 
. dev_attrs =mmc_dev_attrs, 
. match - mme, bus, match, 
. uevent = mme bus uevent, 
. probe = mme, bus probe, 
. remove = mme, bus, remove, 


bs 


. resume 


.pm = MMC_PM_OPS_PTR, 





. suspend = mmc_bus_suspend, 


=mmc_bus_resume, 


static struct bus_type sdio_bus_type = | 


l; 


. name =" sdio", 

. dev_attrs = sdio_dev_attrs, 

. match = sdio. bus, match, 
. uevent = sdio_bus_uevent, 
. probe = sdio, bus, probe, 
. remove = sdio bus, remove, 
.pm = SDIO_PM_OPS_PTR, 


关于 这 两 种 bus 先 来 了 解 MMC 总 线 的 情况 








这 样 是 为 了 避 


static int mmc_bus_match(struct device * dev, struct device_driver * drv) 


| 


| 


match 直接 返回 真 ， 所 以 只 要 是 MMC 总 线 设备 就 会 直接 与 MMC 总 线 驱 动 匹 配 ， 


return 1; 











情况 说 明 MMC 总 线 驱 动 只 有 一 个 ， 并 由 系 








统 框架 已 经 提供 
MMC 总 线 设备 主要 作为 存储 设备 相关 ， 存 储 设备 只 要 提供 统 
层 的 驱动 ) 即 可 。 


现在 对 MMC 总 线 管理 的 设备 还 是 不 清楚 

















static int mme, bus, probe( struct device * dev) 


| 
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struct mme, driver * drv = to. mme. driver( dev —> driver) ; 


struct mmc, card * card = mmc. dev. to. card( dev) ; 


这 样 的 





kt， 可 以 支持 所 有 的 设备 ， 这 与 





一 的 块 设备 驱动 (mme block 





， 继 续 看 一 下 probe 接口 : 


return drv —> probe( card) ; 


| 


从 中 可 见 ，MMC 总 线 设备 主要 就 是 mmc_card， 而 总 线 驱 动 就 是 mme_driver， 在 mmc_ 
driver 的 probe 接口 中 会 对 上 层 的 驱动 相关 的 接口 进行 初始 化 ， 建 立 上 层 与 MMC 总 线 层 的 关 
联 ， 主 要 就 是 与 块 设备 驱动 层 的 关联 。 

这 样 的 设计 与 实现 是 合理 的 ， 因 为 MMC 的 设备 (包括 SD RRE) 主要 用 于 数据 存储 ， 
所 以 块 设备 是 最 合适 的 。 

而 SDIO 则 不 同 ，SDIO 设备 可 以 借助 MMC 总 线 连 接 实现 不 同 的 功能 ， 下 面 看 看 SDIO 
总 线 的 相关 接口 ; 





static int sdio_bus_match( struct device * dev, struct device_driver * drv) 


| 
struct sdio_func * func = dev_to_sdio_func( dev) ; 


struct sdio_driver * sdrv =to_sdio_driver(drv) ; 


if( sdio, match, device( func, sdrv) ) 


return 1; 


return 0; 


| 


从 match 中 可 见 ， 会 涉及 具体 的 总 线 设备 与 总 线 驱 动 的 匹配 ， 这 是 因为 SDIO 可 以 有 不 
同 的 功能 ， 所 以 需要 进行 匹配 。 

SDIO 总 线 管理 的 设备 在 内 核 中 主要 由 sdio fune 来 表示 ， 而 相对 应 的 驱动 则 由 sdio_driv- 
er 来 表示 。 

MMC 整体 框架 如 图 7-10 所 示 。 








Core 
CONFIG MMC 
drivers /m mc/core/ 








Host Drriver 
CONFIG MMC ... 
D viers/m mc/host/--- 
(e.g. omap. hsmmc.c) 








图 7-10 MMC 整体 框架 
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从 图 7-10 nf JU, MMC 主要 管理 两 个 总 线 功能 : MMC 和 SDIO, MMC 总 线 功能 对 应 于 
块 设 备 ， 而 在 SDIO 总 线 之 上 可 以 是 具体 功能 的 设备 。 通 常 一 个 MMC 接口 只 与 一 个 设备 进 
行 连 接 ， 但 是 因为 允许 捅 拔 ， 所 以 需要 能 文 持 检测 、 扫 描 来 文 持 便 件 捅 拔 ， 以 及 不 同 功能 设 





备 的 切换 。 




















MMC 总 线 整体 框架 主 


2. 总 线 控制 器 相关 


要 实现 了 这 些 功 能 。 














在 MMC 框架 中 ， 无 论 是 MMC 总 线 还 是 SDIO 总 线 ， 实 际 的 总 线 控制 器 都 是 相同 的 硬 
件 ， 只 是 协议 中 命令 字 和 状态 机 的 差别 。 在 介绍 MMC 框架 初始 代码 时 见 到 其 中 注册 了 
class， 以 与 MMC 总 线 设备 进行 区 分 ， 相 应 的 class 就 是 为 总 线 控制 器 提供 的 ，MMC 框架 中 
总 线 控制 器 由 mme, host 来 表示 和 管理 ， 细 节 如 下 : 





struct mmc_host | 














// 设 备 层 次 关系 通常 是 platform device 中 的 device 实体 


struct device 


* parent; 








// 设 备 模型 对 应 的 设备 ,属于 mmc_host_class 


struct device 
// 编 号 


int 








class_dev; 


index; 


// V TRO P aS PR EB LI 
const struct mmc, host. ops * ops; 


// 总 线 频率 相关 属性 


unsigned int 
unsigned int 


unsigned int 


// SCHEBU BRE GS , ER E fe VERO FRYE 


u32 
// 接 受 电源 管理 





























f_min; 
f_max; 


f init; 








zn 














ocr, avail ; 




















的 通知 操作 接口 





struct notifier_block pm. notify ; 


/ LV REJI , 3: Je O REJI AE, WN 4/8 bit 传输 ,速度 能 力 等 





unsigned long 




















caps ; / * Host capabilities * / 


// 电 源 管 理 的 能 力 





mmc, pm flag t 


/ * host specific 


pm. caps; / * supported pm features * / 


block data * / 





/ 抉 设 备 相关 的 能 力 信息 ,如 最 大 块 大 小 ,一 个 请 求 的 限制 ,与 控制 器 的 能 力 相 关 


unsigned int 
unsigned short 
unsigned short 
unsigned int 
unsigned int 


unsigned int 


/ * private data 





max, seg size; / * see blk queue max segment size * / 





max, segs; / * see blk queue max segments * / 
unused ; 
max req size; / * maximum number of bytes in one req * / 
max, blk size; / * maximum size of one mmc block * / 


max blk count; / * maximum number of blocks in one req * / 


spinlock_t lock; / * lock for claim and bus ops */ 


// 当 前 MMC IO 接口 的 状态 




















struct mmc. ios ios; / * current io bus settings * / 
/当前 操作 状态 的 设置 

u32 ocr; / * the current OCR setting * / 

/ * group bitfields together to minimize padding * / 

unsigned int use_spi_cre:1; 

// 控 制 器 的 占用 状态 

unsigned int claimed :1; / * host exclusively claimed * / 
unsigned int bus_dead:1; / * bus has been released * / 


/ * Only used with MMC CAP DISABLE * / 
// 当 控制 器 允许 disable 会 有 如 下 属性 








int enabled; / * host is enabled * / 

int rescan, disable; / * disable card detection * / 
int nesting cnt; /* "enable" nesting count * / 

int en_dis_recurs; / * detect recursion * / 

unsigned int disable delay; / * disable delay in msecs * / 
struct delayed_work disable; / * disabling work */ 


/连接 的 MMC 设备 

struct mmc. card * card; / * device attached to this host * / 
// 等 待 操作 的 任务 

wait_queue_head_t wq; 

// 当 前 对 控制 带 进 行 控制 的 任务 


struct task_struct * claimer; / * task that has host claimed */ 





int claim_cnt; /* "claim" nesting count * / 


// HEFT detect 检查 设备 的 work 


struct delayed_work detect; 


/当前 所 属 的 总 线 操作 




















const struct mmc, bus ops * bus. ops; / * current bus driver * / 
unsigned int bus refs; / * reference counter */ 

//SDIO 的 相关 中 断 

unsigned int sdio irqs; 

struct task. struct * sdio irq. thread ; 

atomic t sdio, irq. thread. abort ; 

// 请 求 的 pm 状态 ,通常 与 SDIO card 相关 

mmc, pm flag t pm. flags; / * requested pm features * / 
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可 见 主要 是 对 总 线 控制 器 的 操作 能 力 以 及 状态 进行 设置 ， 这 些 操 作 能 力 相 关 的 都 是 属于 
相关 规范 的 物理 特性 ， 需 要 通过 这 些 属 性 标注 总 线 控制 器 物理 能 力 。 另 外 重要 的 就 是 两 个 操 
ERHO, 分 别 是 mmce. host _ops 和 mmc_bus _opso 

先 来 看 看 mme, host. ops : 














struct mmc_host_ops | 


E 








// 电 源 管 理 相 关 的 enable 和 disable 操作 接口 


int( * enable) (struct mmc_host * host) ; 














int( * disable) (struct mme, host. * host, int lazy) ; 


// 传 输 的 操作 接口 


void( * request) (struct mme host * host, struct mme, request * req) ; 


//10 状态 的 设置 接口 

void( * set, ios) (struct mmc, host * host, struct mmc, ios * ios); 
// 获 得 只 读 状 态 

int ( * get ro) (struct mme host * host) ; 

// 获 得 当前 card 是 否 在 位 的 状态 

int ( * get ed) (struct mme, host. * host) ; 

// 对 SDIO 接口 中 断 enable 和 disable 的 操作 接口 

void( ** enable_sdio_irq) ( struct mme, host * host, int enable) ; 
// 可 选 的 对 设备 初始 化 的 接口 


void( * init_card) (struct mmc_host * host, struct mmc_card * card) ; 





这 里 主要 是 控制 和 进行 传输 操作 的 接口 ， 是 进行 实际 总 线 控制 器 操作 的 接口 ， 真 正 的 传 
输 也 是 通过 总 线 控制 需 来 完成 的 。 
mmc, bus ops 接口 细节 如 下 : 





struct mmc_bus_ops | 


E 


int( * awake) (struct mme, host. * ) ; 

int( * sleep) (struct mme, host. * ) ; 

void( * remove) (struct mme, host * ) ; 
void( * detect) (struct mmc, host. * ) ; 
int( * suspend) (struct mme host * ) ; 
int( * resume) (struct mme, host. * ) ; 
int( * power save) (struct mme host * ) ; 


int( * power. restore) (struct mme host * ) ; 











需要 mme, bus, ops 的 原因 是 因为 MMC 总 线 可 以 支持 不 同 协议 规范 的 设备 ， 这 些 设备 相 
关 的 操作 是 不 同 的 ， 所 以 在 控制 带 中 提供 相应 的 操作 接口 ， 这 样 在 总 线 设备 侦 测 时 就 可 以 根 
据 设 备 的 特点 加 载 合 适 的 操作 接口 。 在 相应 的 操作 中 ，detect 是 检测 设备 是 否 存在 ， 其 他 大 
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多 与 电源 管理 相关 ， 通 过 规范 的 命令 可 以 完成 相应 的 操作 。 
MMC 总 线 控制 器 框架 提供 了 创建 的 接口 mmc_alloc_host， 主 要 内 容 如 下 : 














struct mmc, host * mmc_alloc_host( int extra, struct device * dev) 
int err; 


struct mme, host * host; 


if( | idr. pre. get( &mme, host, idr, GFP. KERNEL) ) 
return NULL; 
// 分 配 空间 ,这 里 会 为 总 线 控制 器 设备 相关 的 管理 实体 分 配 空间 大 小 为 extra 
host = kzalloc( sizeof( struct mmc_host) + extra, GFP_KERNEL) ; 
if( | host) 
return NULL; 




















spin, lock( &mme, host. lock) ; 
// 获 得 新 的 编号 ,建立 ID 号 和 管理 实体 指针 间 的 关联 


err = idr_get_new( &mmc_host_idr, host, &host -> index) ; 





spin, unlock( &mme, host, lock) ; 
if( err) 
goto free; 
// 设 置 设备 模型 相关 的 名 字 
dev_set_name( &host —» class dev, "mmc% d" , host -> index) ; 
/人 /设备 模型 相关 初始 化 


host —» parent = dev; 





host -> class, dev. parent = dev; 
host —> class, dev. class = &mmce. host, class; 


device, initialize( &host -> class, dev) ; 


spin, lock, init( &host —» lock) ; 

// 初 始 化 不 同 任务 操作 控制 器 的 等 待 队 列 

init_waitqueue_head( &host -> wq) ; 

]/ 初 始 化 探测 设备 的 work 

INIT_DELAYED_WORK( &host -> detect, mmc_rescan) ; 

// 初 始 化 电源 管理 相关 的 work 

INIT_DELAYED_WORK_DEFERRABLE( &host -> disable ,mmc_host_deeper_disable) ; 

#ifdef CONFIG_PM 

// 电 源 管理 相关 的 通知 操作 接口 

host -> pm. notify. notifier call = mmc. pm. notify ; 


#endif 


























// 设 置 操作 的 能 


645 


host -> max segs = 1; 


host -> max seg size = PAGE CACHE SIZE; 


host — > max req. size = PAGE CACHE SIZE; 
host -> max, blk. size 2512; 
host -> max, blk. count = PAGE, CACHE, SIZE / 512; 


return host ; 


主要 的 操作 是 分 配 空间 ， 并 初始 化 与 功能 相关 的 work， 其 中 最 重要 的 是 探测 设备 的 
work， 相 应 的 操作 是 mmc_rescan， 后 面 会 进行 介绍 。 
接 下 来 的 接口 是 注册 并 初始 化 控制 器 便 件 的 接口 mmc_add_host， 详 细 内 容 如 下 : 

















int mme, add, host( struct mmc_host * host) 


| 


int err; 


// 注 册 设 备 模 型 
err = device_add( &host -> class dev); 
if( err) 


return err; 





// Je SV BPE i i 

mmc_start_host( host) ; 

/注册 相应 电源 管理 通知 的 操作 

if(! (host —» pm. flags & MMC. PM. IGNORE. PM. NOTIFY) ) 


register pm. notifier( &host -> pm, notify) ; 














return 0; 





在 调用 mmc, add, host 之 前 ， 需 要 将 mmc, host, ops 初始 化 ， 并 将 控制 需 的 相关 属性 进行 
正确 设置 。 其 中 最 重要 的 操作 就 是 mmc_start_host， 会 通过 mmc, detect change 唤醒 控制 器 的 
detect work, RAMIE mme rescan 来 进行 设备 探测 ， 这 实现 了 MMC 总 线 设 备 发 现 的 重要 
功能 ， 详 细 分 析 如 下 : 
































void mmc_rescan( struct work_struct * work ) 
| 
// 先 获得 总 线 控制 器 实体 


struct mmc. host * host = 
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container_of( work, struct mmc_host, detect. work) ; 
u32 ocr; 
int err; 
unsigned long flags; 
int 1; 
const unsigned freqs[ | = | 400000, 300000, 200000, 100000 | ; 


int extend_wakelock =0; 


spin_lock_irgsave( &host —» lock, flags) ; 
// 如 果 不 允许 探测 则 返回 
if( host —» rescan, disable) | 





spin, unlock, irqrestore( &host -> lock, flags) ; 


return; 


spin, unlock, irqrestore( &host -> lock, flags) ; 

/人 /计数 并 使 能 控制 天 

mme, bus, get( host) ; 

// 如 果 设备 可 以 移 除 ,检查 设备 是 否 存在 

if( host -> bus ops && host -> bus ops —» detect &&! host -> bus, dead 











&& mmo, card, is. removable( host) ) 


host -> bus. ops —> detect( host) ; 


mme. bus, put( host) ; 
mme, bus, get( host) ; 
/ * if there still is a card present, stop here * / 
// detect 操作 已 经 发 现 合 适 设备 则 退出 
if( host ->bus_ops! = NULL) | 
mme, bus, put( host) ; 
goto out; 
} 
mmc_bus_put( host) ; 
/检测 到 没有 设备 存在 
if( host -> ops —» get_cd && host -> ops -> get, ed( host) ==0) 
goto out; 
/人 /按照 总 线 频率 从 高 到 低 探测 设备 
for(i =0; i < ARRAY SIZE(freqs) ; i++ ) | 
// 声 明 占 用 控制 需 
mmc_claim_host( host) ; 
// 设 置 总 线 频率 值 
if( freqs[ i] >= host -> f. min) 























host —» f. init = freqs[ i] ; 
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else if( li || freqs[i-— 1] > host -> f min) 
host —> f init = host -> f min; 

else | 
mme, release host( host) ; 


goto out ; 


mme. power. up( host) ; 
sdio. reset( host) ; 


mme. eo. idle( host) ; 
mmc, send. if cond( host, host —> ocr. avail) ; 


// 首 先 检测 是 否 是 SDIO 

err = mme, send, io. op. cond( host, 0, &ocr) ; 

if( Ferr) | 
/特殊 命令 操作 成 功 则 绑 定 SDIO 相关 bus ops, 以 及 对 SDIO 设备 
// 进 行 检测 初始 化 
if( mmc. attach, sdio( host, ocr) ) | 





mmce. claim, host( host) ; 
// 检 测 不 成 功 则 检查 是 否 是 SD 设备 
if( mme, send, app. op. cond( host, 0, &ocr) ) 
goto out, fail ; 
// 特 殊 命 令 操 作成 功 则 绑 定 SD 相关 bus ops ,以 及 对 SD 设备 
// 进 行 检测 初始 化 
if( mmc, attach, sd( host, ocr) ) 
mme, power. off( host) ; 
extend. wakelock - 1 ; 
} 
goto out; 
} 
/检测 是 否 是 SD 设备 
err =mmc_send_app_op_cond(host, 0, &ocr) ; 
if( Ferr) | 
// 特 丈 命令 操作 成 功 则 绑 定 SD 相关 bus ops ,以 及 对 SD 设备 
// 进 行 检测 初始 化 
if( mme_attach_sd( host, ocr) ) 
mme. power. off( host) ; 
extend. wakelock = 1 ; 
goto out; 
} 
// 检 测 是 否 是 MMC 设备 
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err =mmc_send_op_cond(host, 0, &ocr) ; 

if( Ferr) | 
// 特 丈 命令 操作 成 功 则 绑 定 MMC 相关 bus ops, 以 及 对 MMC 设备 
// 进 行 检测 初始 化 


if(mmc_attach_mmc(host, ocr) ) 





mme. power. off( host) ; 
extend, wakelock = 1 ; 


goto out ; 


out, fail ; 
mme, release. host( host) ; 


mme. power. off( host) ; 


可 见 主要 的 工作 就 是 探测 设备 ， 并 在 探测 成 功 后 通过 mme, attach. xxx 来 初始 化 总 线 控 
制 器 的 bus ops 接口 ， 并 对 总 线 设备 进行 初始 化 操作 。 

这 样 总 线 的 主要 功能 ， 包 括 总 线 传输 事务 以 及 总 线 设备 发 现 ， 就 都 在 代表 MMC 总 线 的 
MMC 总 线 控制 右 部 分 有 了 完整 文 持 。 

3. 总 线 设 备 相 关 

前 面 已 经 提 及 ，MMC 总 线 设 备 管理 由 mme_card 来 完成 。 下 面具 体 介绍 


























struct mmc_card | 


// 关 联 的 总 线 探 制 器 






































struct mmc_host * host; / * the host this device belongs to * / 
/设备 模型 实体 

struct device dev; / * the device */ 

//SD 需要 的 相对 card 地 址 

unsigned int rea; / * relative card address of device * / 
// card 的 类 型 主要 是 MMC SD ,SDIO 或 者 SDIO/SD combo 的 

unsigned int type; / * card type */ 

// card 的 状态 ,如 是 否 只 读 、 速 度 状 态 等 

unsigned int state; / * (our) card state * / 

// 特 殊 属 性 

unsigned int quirks; /* card quirks */ 

// 擦 除 相关 的 属性 ,由 于 基于 nand 的 存储 架构 ,所 有 需要 擦 除 相 关 的 属性 
unsigned int erase, size; / * erase size in sectors * / 
unsigned int erase, shift ; / * if erase unit is power 2 * / 
unsigned int pref erase; /* in sectors */ 

u8 erased_byte; / * value of erased bytes * / 
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//card 上 相关 寄存 器 的 raw 值 

















u32 raw_cid| 4 | ; / * raw card CID */ 

u32 raw. esd[ 4] ; /* raw card CSD */ 

u32 raw. scr[ 2] ; /** raw card SCR */ 
/转换 后 的 MMC card 上 相关 属性 

struct mmc_cid cid; / * card identification * / 
struct mmc_csd csd; / * card specific */ 
struct mmc_ext_csd ext_csd; / * mmc v4 extended card specific * / 
// 转 换 后 的 SD card 上 相关 属性 

struct sd. scr Scr; / * extra SD information * / 
struct sd. ssr SSr; / * yet more SD information * / 
struct sd. switch. caps sw caps; / * switch( CMD6) caps */ 


//SDIO 一 个 card 上 可 以 支持 多 个 功能 ,这 里 是 功能 数目 








unsigned int sdio_funcs ; / * number of SDIO functions * / 
/转换 后 的 SDIO card 上 相关 属性 

struct sdio_cccr cccr; / * common card info * / 
struct sdio_cis cis; / * common tuple info * / 


//SDIO 每 个 功能 的 管理 实体 ,每 个 功能 在 逻辑 上 都 相当 于 一 个 设备 
struct sdio func — * sdio func[ SDIO_MAX_FUNCS]; / * SDIO functions(devices) * / 
// 一 些 信息 























unsigned num_info; / * number of info strings * / 
const char * * info; / * info strings * / 
struct sdio func, tuple * tuples; — /* unknown common tuples */ 
struct dentry * debugfs_root; 


E 








从 中 可 见 ， 为 了 支持 MMC/SD/SDIO 等 不 同 的 协议 规范 ， 其 中 的 属性 都 在 mme, card 中 
进行 了 表示 ， 具 体 的 类 型 和 对 应 的 属性 都 会 在 设备 发 现 阶 段 进 行 初始 化 。 
MMC 设备 的 管理 框架 提供 了 相应 的 创建 和 注册 接口 。 首 先 来 了 解 创建 的 接口 mme 


alloc_card : 

















struct mme, card * mmc_alloc_card( struct mmc_host * host, struct device type * type) 


| 
struct mmc_card * card; 
// 分 配 空间 
card = kzalloc( sizeof( struct mme. card) , GFP_KERNEL) ; 
if( ! card) 
return ERR, PTR( - ENOMEM) ; 
// Ej EX AS ill X 
card —> host = host; 
/人 /设备 模型 信息 的 初始 化 
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device, initialize( &card -> dev) ; 
// 设 备 层次 关联 ,总 线 设置 


card —> dev. parent = mmc_classdev( host) ; 


card —> dev. bus = 


&mmc_bus_type; 


card —> dev. release = mmc_release_card ; 


card —> dev. type = type; 


return card; 


| 


主要 进行 设备 模型 相关 的 设置 。 下 面 的 接口 是 用 于 注册 的 ， 详 细 内 容 如 下 : 





int mmc. add, card( struct mmc_card * card) 


| 
int ret; 


const char * type; 


/根据 控制 器 名 字 和 卡 的 相对 card 地 址 创建 设备 名 字 


dev_set_name( &card -> dev, "%s:%04x" , mmc_hostname( card —» host) , card —» rca) ; 





// EAT IC BERE 


EI 











ret = device, add( &card -> dev) ; 


if( ret) 


return ret; 


/设置 卡 存在 的 状态 


mmc_card_set_present( card ) ; 


return 0; 


| 


可 见 主要 的 工作 与 设备 模型 相关 ， 当 向 设备 模型 注册 了 device 之 后 ， 就 会 通过 总 线 来 进 
行 驱动 的 probe 操作 。 对 MMC 驱动 ， 之 前 已 经 说 明 只 有 MMC block 提供 的 mmcblk 驱动 ， 详 





细 内 容 如 下 : 


static struct mmo, driver 














mmc, driver = | 


. drv EX 
. name ="mmeblk" , 
b. 
. probe = mmc, blk probe, 
. remove - mme, blk remove, 


. suspend = mme, blk suspend, 


. resume -mmoe, blk resume, 
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主要 与 块 设 备 层 关联 的 工作 是 由 mmc_blk_probe 来 完成 的 ， 下 面 来 看 看 细节 : 





static int mme, blk probe( struct mme, card. * card) 
struct mme, blk data * md; 
int err; 


char cap. str[ 10] ; 


// 检 查 设备 是 否 文 持 块 读 取 , 驱 动 需要 设备 允许 块 读 取 
if(! (card —» csd. emdclass & CCC_BLOCK_READ) ) 
return - ENODEV; 
// 这 里 分 配 MMC 驱动 相关 的 块 设 备 管理 实体 ,其 中 会 创建 块 设备 层 需要 的 
// 的 gendisk ,并 通过 blk_init_queue 初始 化 request queue 操作 
md = mmc_blk_alloc( card) ; 
if(IS_ERR(md) ) 
return PTR_ERR( md) ; 
// 设 置 操 作 大 小 512B ,与 Linux 块 设备 层 一 至 
err =mmce_blk_set_blksize( md, card) ; 


if( err) 



































goto out ; 








// 为 设备 模型 设置 管理 实体 ,以 进行 电源 管理 相关 操作 
mmc_set_drvdata( card, md) ; 

// 加 入 Linux 块 设备 层 
add, disk ( md -> disk) ; 


return 0; 




















| 
从 分 析 中 可 见 ， 通 过 mmeblk 驱动 就 可 以 将 MMC 设备 与 块 驱 动 层 建立 关联 ， 进 而 可 以 


被 文件 系统 和 应 用 使 用 。 至 于 request queue 的 操作 ， 在 MMC block 层 mmc. init queue 中 单独 
创建 了 kthread 进行 相应 操作 . 











mq —> thread = kthread_run( mme, queue, thread, mq, "mmeqd/%d" , host —> index) ; 





在 mmc, queue, thread 中 则 从 request queue 中 获得 request 再 通过 mmc, queue 的 issue, fn 
接口 即 mme_blk_issue_rq 来 真正 执行 相应 的 request。 这 样 MMC 作为 存储 设备 的 功能 就 完 
整 了 。 

SDIO 总 线 设备 由 sdio func 进行 管理 ， 其 详细 内 容 就 不 进行 分 析 了 ， 与 mme. card XW, 
包含 一些 属性 ， 但 是 由 于 SDIO 中 的 data0 可 以 作为 中 断 源 ， 所 以 其 中 包含 中 断 的 属性 ， 总 
线 榨 制 器 与 mme_card 没有 差别 ， 所 以 不 需要 单独 关联 。MMC 框架 也 提供 了 创建 和 注册 
SDIO 设备 的 接口 。 先 来 看 看 创建 的 接口 sdio_alloc_func: 
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struct sdio func * sdio_alloc_func( struct mme, card. * card) 
| 

struct sdio_fune * func; 

// 分 配 空间 

func = kzalloc( sizeof( struct sdio func) , GFP_KERNEL) ; 

if( ! func) 

return ERR, PTR( - ENOMEM) ; 

//*j MMC 设备 关联 

func —> card = card; 

// 设 备 模型 初始 化 

device_initialize( &func -> dev) ; 

// 注 意 这 里 的 设备 层次 和 总 线 类 型 关系 

func -> dev. parent = &card -> dev; 

func -> dev. bus = &sdio_bus_type; 


func —> dev. release = sdio_release_func ; 


return func; 


| 








从 分 析 中 可 见 ，SDIO 设备 并 不 是 修改 mme, card 中 的 dev 属性 ， 而 是 拥有 单独 设备 模型 
实体 ， 在 设备 层次 中 其 父 设备 是 mmc_card， 这 与 设备 的 逻辑 层次 相符 ， 而 mme, card 在 sdio 
func 中 起 到 了 中 介 作 用 。 

再 来 看 看 设备 注册 的 接口 sdio add fune: 




















int sdio_add_func ( struct sdio_fune * func) 
| 
int ret; 
// 根 据 card 号 以 及 function 编号 
dev_set_name( &func —» dev, "%s:%d" , mmc_card_id(fune —» card) , func -> num) ; 
// 回 设备 模型 进行 注册 
ret = device_add( &func -> dev) ; 
if( ret ==0) 


sdio, fune, set. present( func) ; 


return ret ; 


| 





可 见 主要 的 操作 也 是 向 设备 模型 进行 注册 ， 注 册 后 就 通过 总 线 操 作 查 找 匹 配 的 驱动 并 绑 
定 ， 就 可 实现 其 相关 功能 。 
对 不 同 规范 类 型 的 设备 ， MMC 框架 通过 mme. xxx. init. card 和 mmc_attach_xxx 等 接口 封 
装 了 以 上 的 操作 来 实现 设备 的 创建 与 注册 ， 这 些 都 是 在 设备 发 现 阶段 完成 的 。 
在 设备 发 现 阶 段 MMC 主要 依靠 探测 发 现 的 方式 进行 ， 当 card 有 揪 拔 的 时 候 同 样 需 要 进 
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行 设备 的 重新 发 现 与 探测 ， 











醒 总 线 控制 器 的 detect 操作 即 mmc_rescan XH 


况 进行 相关 操作 。 
4. 总 线 传输 接口 
MMC 框架 是 





struct mmc. request | 


进行 操作 的 命令 


struct mmc_command 


// 相 关 的 数据 
struct mmc. data 


/操作 结束 的 命令 





struct mmc_command 


// FIERE RS BL 


void 
/人 /同步 操作 的 接口 
void 


bs 


在 总 线 层 所 有 的 传输 都 是 通过 mme, request 来 进行 实际 操作 。 


for req， 下 面 来 看 看 细节 : 


MMC 框架 为 这 种 情况 提供 


* done_data; 








FE 了 接口 mmc_detect_change， 其 中 会 唤 
新 detect 总 线 设 备 的 情况 ， 并 根据 当前 设备 情 

















通过 mme. request 管理 MMC 总 线 传 输 ， 细 节 如 下 : 


* cmd; 


* data; 


* stop; 


/ * completion data * / 


( * done) ( struct mme, request * ) ;/ * completion function * / 





具体 的 接口 是 mme. wait. 


void mme, wait, for req( struct mme, host * host, struct mmc, request ** mrq) 


| 


| 


可 见 主要 是 以 同步 的 方式 进行 


DECLARE_COMPLETION_ONSTACK ( complete ) ; 


人/ 设置 完成 同步 参数 和 操作 接口 
mrq —> done, data = &complete ; 
mrq —> done = mmc, wait, done; 
/开始 操作 

mmc_start_request( host, mrq) ; 
/等 待 完成 


wait_for_completion( &complete ) ; 





quest 来 完成 的 ， 细 节 如 下 : 








总 线 传输 操作 的 ， 具 体操 作 的 发 起 是 通过 mme. start. re- 


static void mmc, start, request( struct mmc_host * host, struct mme request * mrq) 


| 


654 


// il ae ET BI b zv 





led. trigger. event( host -» led, LED. FULL) ; 


| 


总 线 传输 基本 操作 是 先 发 送 命令 ， 然 后 进行 数据 操作 ， 接 下 来 结束 命令 。 实 际 操作 中 后 


// 初 始 化 状态 并 与 req 进行 

mrq -> cmd —> error =0; 

mrq —» cmd -> mrq = mrq; 

if( mrq —> data) | 
// RAE ETRE ,不 能 超过 控制 器 的 范围 
BUG. ON( mrq -> data ->blksz > host -> max, blk size) ; 
BUG. ON( mrq -> data -> blocks > host -> max, blk count) ; 





BUG, ON( mrq -> data -> blocks * mrq -> data -> blksz > 


host -> max, req. size) ; 


/人 /初始 化 数据 部 分 状态 ,并 与 req 进行 关联 

mrq -> cmd —> data = mrq —> data; 

mrq —> data —> error =0; 

mrq —> data —» mrq = mrq; 

if( mrq —> stop) | 
// 如 果 需 要 stop 命令 ,初始 化 状态 信息 并 与 req 进行 关联 
mrq —> data 一 > stop = mrq 一 > stop; 





mrq -> stop —> error =0; 


mrq —> stop -> mrq = mrq; 


} 
// LARTE i a ET ERE 
host —» ops —> request ( host, mrq) ; 

















两 步 可 选 ， 在 完整 的 操作 中 任何 一 步 有 了 问题 都 会 导致 整个 操作 失败 ， 相应 的 mmc. request 


中 同样 分 为 三 步 ， 并 在 三 步 的 实体 中 都 关 有 





最 终 直 接 调 用 mmc. wait for req 来 完成 。 
除了 数据 等 稍微 复杂 的 传输 操作 之 外 ，MMC 框架 对 简单 的 命令 发 送 还 提供 了 mme. wait 
_for_cmd 接口 来 执行 相关 操作 。 细 节 如 下 : 








KEJ mmc_request 来 保证 正确 处 理 。 块 设备 的 传输 








int mmc, wait, for. cmd( struct mmc_host * host, struct mme, command * cmd, int retries ) 


| 


struct mmc_request mrq; 


WARN. ON( ! host -> claimed) ; 

// 初 始 化 mme. request 

memset( &mrq, 0, sizeof( struct mme, request) ) ; 

// 初 始 化 命令 的 响应 数据 ,响应 respond ; 规范 中 规定 不 同 命令 的 不 同 响应 格式 
memset( cmd -> resp, 0, sizeof( cmd —> resp) ) ; 


// 重 试 次 数 
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cmd —> retries = retries ; 
// 命 令 

mrq. cmd = cmd; 

cmd —> data = NULL; 
// 等 待 同步 完成 


mmc_wait_for_req( host, &mrq) ; 





return cmd —> error; 


| 





可 见 主要 的 操作 就 是 对 mme, wait. for req 的 简单 封装 ， 其 中 主要 是 为 了 命令 的 操作 。 

MMC/SD/SDIO 规范 中 都 规定 了 一 些 特 殊 的 操作 和 命令 ， 虽 然 这 些 操作 最 终 都 是 通过 以 
上 的 接口 执行 的 ， 但 是 为 了 方便 开发 MMC 框架 分 别提 供 了 相应 的 接口 进行 相关 操作 ， 具 体 
的 操作 可 以 参考 规范 的 说 明 。 上 有 具体 的 接口 如 下 : 








//MMC 相关 的 操作 

int mme, send, op. cond( struct mme, host * host, u32 ocr, u32 * rocr); 
int mmc. all, send, cid( struct mme. host * host, u32 * cid); 

int mmc. set, relative addr( struct mmc, card. * card) ; 

int mmc. send, esd( struct mme, card * card, u32 * csd); 

int mme. send, ext, csd( struct mmc, card * card, u8 * ext_csd) ; 

int mme. switch( struct mme, card. * card, u8 set, u8 index, u8 value) ; 
int mmc. send, status( struct mmc, card * card, u32 * status); 


int mme. send, cid( struct mme. host * host, u32 * cid); 


//SD 相关 的 操作 

int mme, app. set. bus, width( struct mme, card * card, int width) ; 

int mme, send, app. op. cond( struct mme, host * host, u32 ocr, u32 * rocr); 

int mme. send, if cond( struct mmc, host * host, u32 ocr); 

int mme, send, relative addr( struct mme, host * host, unsigned int * rca); 

int mme, app. send. ser(struct mme, card * card, u32 * scr); 

int mme, sd. switch( struct mme, card * card, int mode, int group, u8 value, u8 * resp); 


int mme, app. sd, status( struct mme, card * card, void * ssr); 


//SDIO 相关 的 操作 
int mme, send, io op. cond( struct mme, host * host, u32 ocr, u32 * rocr) ; 
int mme, io rw. direct( struct mme, card * card, int write, unsigned fn, 
unsigned addr, u8 in, u8 * out); 
int mme, io rw, extended( struct mme, card * card, int write, unsigned fn, 
unsigned addr, int incr_addr, u8 * buf, unsigned blocks, unsigned blksz) ; 


int sdio, reset( struct mme, host * host) ; 


这 样 整个 命令 操作 以 及 传输 功能 就 完整 了 。 
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7.3.3 TI 芯片 MMC 相关 实现 详解 


DM 3730 的 MMC 控制 器 框架 如 图 7-11 所 示 。 图 7-11 引 自 《DM 3730 芯片 手册 》 中 第 
3398 页 的 框图 。 
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| 7-11 DM 3730 MMC 框架 区 


从 图 7-11 nS, MMC 控制 器 中 有 复杂 的 命令 和 数据 管理 ， 控 制 器 内 部 带 有 buffer 用 于 
数据 缓冲 ， 数 据 主 要 通过 DMA ROS, 

关于 DM 3730 MMC 的 驱动 部 分 ， 主 要 分 析 其 相关 的 初始 化 和 总 线 传 输 以 及 card 状态 变 
化 的 操作 。 

1. 初始 化 

先 来 看 看 初始 化 部 分 ， 这 里 还 是 通过 platform driver 的 probe 函数 来 了 解 细 节 ， 其 内 容 如 下 : 














static int __init omap_hsmmc_probe(struct platform. device * pdev) 


| 


struct omap_mmc_platform_data * pdata = pdev -> dev. platform. data; 
struct mmc, host * mmc; 

struct omap_hsmmc_host * host = NULL; 

struct resource * res; 


int ret, irq; 
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if( pdata == NULL) | 
dev_err( &pdev -> dev, "Platform Data is missing\n" ) ; 
return — ENXIO ; 
} 
如果 没有 槽 一定 是 错 的 
if( pdata -> nr. slots ==0) | 
dev. err( &pdev -> dev, "No Slots \n" ) ; 
return — ENXIO ; 





} 
// IRIA TE te HH Te ER 
res = platform, get, resource( pdev, IORESOURCE MEM, 0) ; 
// 获 得 中 断 号 
irq = platform, get, irq( pdev, 0) ; 
if(res == NULL || irq <0) 

return — ENXIO ; 





// BE FE BS ins E] . 


res —» start + = pdata —» reg. offset ; 








res -» end + = pdata -> reg offset; 





res = request mem region( res -> start, res -» end — res —» start + 1, pdev -> name) ; 
if(res == NULL) 
return — EBUSY; 


//card detect 的 GPIO 相关 的 初始 化 ,如 没有 相应 GPIO 作为 card 检测 
// 则 该 操作 实际 为 空 

ret = omap. hsmmce, gpio, init( pdata ) ; 

if( ret) 


goto err; 





// 分 配 相 应 的 mme 框架 层 的 mme host, 以 及 设备 特殊 结构 omap, hsmme, host 
// 为 附加 信息 
mme = mmc_alloc_host( sizeof( struct omap_hsmmc_host) , &pdev -> dev) ; 
if( ! mmc) | 

ret = — ENOMEM; 











goto err_alloc; 








// 对 于 mme 层 的 mme host 结构 附加 的 omap_hsmmc_host 进行 初始 化 
host =mmc_priv( mmc) ; 

// 建 立 mmc host 和 omap hsmme 的 关联 

host ->mmc =mmc; 


//platform special data 和 slot 相关 
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host -> pdata = pdata; 





host -> dev = &pdev -> dev; 
// fii f DMA 
host -> use dma EE 











zu 


//DMA 地 址 范 目 
host -> dev -> dma mask = &pdata -> dma, mask ; 








host -> dma ch = -1; 

//irq 5 

host —> irq = irq; 

// 记 录 MMC 接口 D 

host -> id = pdev -> id; 

// A~ MMC controller 只 接 一 个 slot 
host -> slot id =0; 





// 寄 存 器 物理 基地 址 

host -> mapbase = res 一 > start; 

/映射 基地 址 

host —» base = ioremap (host ~ > mapbase, SZ 4K) ; 


host -> power. mode = MMC POWER, OFF; 


// 设 置 私 有 的 drv data 便于 pm 部 分 代码 使 用 

platform, set. drvdata( pdev, host) ; 

// 创 建 work , work 的 执行 实体 为 omap_hsmmc_detect 

INIT_WORK( &host -> mmc_carddetect_work , omap. hsmme, detect) ; 











// 根 据 参数 设置 挂 载 不 同 的 控制 器 操作 接口 
if( mme, slot( host). power, saving) 

mmc —> ops = &omap_hsmmc_ps_ops; 
else 


mmc —> ops = &omap_hsmmc_ops; 


if( mme, slot( host). vec, aux, disable is sleep) 


mme, slot( host). no off 1; 


/总 线 频率 的 范围 

mmc —>f_min = 400000; 

mme —> f _max =52000000; 
spin_lock_init( &host —» irq_lock) ; 
// 获 得 时 钟 


host -> iclk = clk_get( &pdev -> dev, "ick" ); 
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host ->fclk = clk_get( &pdev -> dev, "fck" ) ; 


//MMC 上 下 文保 存 


omap_hsmmc_context_save (host) ; 


/设置 MMC 可 以 disable 的 能 力 

mmc 一 > caps | = MMC_CAP_DISABLE; 

// 设 置 mme 层 host controller 超时 多 少 之 后 可 以 disable controller 
mmc_set_disable_delay( mmc, OMAP_MMC_DISABLED_TIMEOUT) ; 
/ * we start off in DISABLED state */ 

// 设 置 host controller 的 power 状态 为 disable 

host -> dpm_state = DISABLED; 


//enable 必需 的 clock 

if( clk enable( host -> iclk) ! 20) | 
clk_put( host -> iclk) ; 
clk_put( host -> felk) ; 
goto errl ; 

| 

// 使 能 控制 器 

if( mme, host. enable( host -> mmc) ! =0) | 
clk, disable( host -> iclk) ; 
clk_put( host -> iclk) ; 
clk_put( host -> felk) ; 


goto errl ; 





/ * Since we do only SG emulation, we can have as many segs 
* as we want. */ 
// 下 面 的 参数 是 block layer 相关 的 参数 ,对 于 优化 性 能 是 有 意义 的 


mmc —>max_segs =1; 





mmc —> max, blk size 2512; / * Block Length at max can be 1024 ** / 
mmc 一 > max, blk count =OxFFFF; / * No. of Blocks is 16 bits */ 
mmc —» max req size = mmc —» max blk size * mmc -> max, blk count; 


mmc —» max, seg. size = mmc 一 > max req. size; 














//mme 相关 的 能 力 属 性 设置 ,这 里 主要 是 设置 高 速 mmc/sd high speed 
mme -> caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED | 
MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_ERASE; 


























mmc 一 > caps | - mmc, slot( host). caps; 
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if( mme —> caps & MMC_CAP_8_BIT_DATA) 
mmc —> caps | - MMC CAP 4 BIT DATA; 














// ROASTERS PHY AP BÉ HS D TRUE Jt HE 
if( mme, slot( host). nonremovable ) 


mmc —> caps | = MMC_CAP_NONREMOVABLE; 


























mmc —» pm. caps | = MMC PM KEEP POWER; 
omap. hsmmce. conf bus power( host) ; 


// 3&4 DMA 信息 
res = platform. get. resource( pdev, IORESOURCE_DMA, 0) ; 
if( ! res) 

goto errl ; 
host -> dma, line, rx = res 一 > start; 
res = platform. get. resource( pdev, IORESOURCE DMA, 1); 
if( ! res) 

goto errl ; 


host -> dma_line_tx = res 一 > start; 


/ * Request IRQ for MMC operations * / 
/人 /相关 中 断 初始 化 
ret = request, irq( host -> irq, omap_hsmmc_irg, IRQF_DISABLED ， 
mme, hostname( mmc) , host) ; 
if( ret) | 
dev. dbg( mme, dev( host -> mmc) , " Unable to grab HSMMC IRQ\n" ) ; 


goto err irq; 


/ * Request IRQ for card detect */ 
// card detect 中 断 信号 
if( ( mme, slot( host). card, detect, irq) ) | 
ret = request. irq( mmc, slot( host). card. detect, irq, omap. hsmme, cd. handler, IRQF  TRIG- 
GER, RISING | IRQF_TRIGGER_FALLING | IRQF DISABLED, mmc_hostname( mmc) , host) ; 
if( ret) | 
dev. dbg( mme, dev( host -> mmc) , 
"Unable to grab MMC CD IRQ n") ; 
goto err irq cd; 
| 
pdata -> suspend = omap_hsmmc_suspend_cdirq; 


pdata -> resume = omap_hsmmc_resume_cdirq; 
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| 


从 分 析 中 可 见 ， 主 要 的 工作 是 进行 


omap. hsmme, disable irq( host) ; 


mme. host. lazy, disable( host -> mmc) ; 
// X] card 进行 保护 ,避免 不 正确 的 写 损坏 卡 


omap. hsmme, protect, card( host) ; 


向 MMC 框架 注册 总 线 控制 器 ,其 后 会 进行 设备 发 现 相 关 操作 


mmc_add_host( mmc ) ; 














// 创 建 sysfs 中 操作 接口 

if(mmc_slot(host). name! = NULL) | 
ret = device, create, file( &mme -> class dev, &dev_attr_slot_name) ; 
if( ret <0) 

goto err. slot, name; 

} 

if(mmc_slot( host). card_detect_irq && mmo, slot( host). get, cover. state) | 
ret = device, create, file( &mme -> class dev, &dev. attr. cover. switch) ; 
if( ret <0) 


goto err slot name; 


omap. hsmme, debugfs ( mmc) ; 


return 0; 





add, host 的 调用 实现 功能 。 


相应 的 platform device 是 在 系统 初始 化 时 通过 omap_mmc_add tí 


述 了 。 





2. 总 线 传输 
总 线 传输 的 控制 需 接 口 是 由 mme, host, ops 中 的 request 来 定义 的 ，DM 3730 MMC fils 
相应 的 操作 是 omap_hsmmc_request。 下 面 详细 分 析 其 功能 : 





属性 设置 、 资 源 申 请 和 接口 注册 ， 


然后 通过 mmc_ 








和 4， 这 里 就 不 详 


static void omap, hsmme, request( struct mme, host * mmc, struct mme, request * req) 


| 
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struct omap_hsmmc_host * host = mme, priv( mmc) ; 


int err; 


BUG_ON (host -> req. in. progress) ; 
BUG, ON( host -> dma ch! = -1); 


if( host -> protect_card) | 
/在 保护 阶段 的 传输 请 求 都 直接 报错 
if( host —» reqs_blocked <3) | 


omap. hsmme, reset, controller fsm(host, SRD) ; 





omap. hsmme. reset, controller fsm( host, SRC) ; 





host -> reqs blocked + =1; 
| 
req -> cmd —> error = - EBADF; 
if( req -> data) 
req —> data -> error = - EBADF; 
req —> cmd —> retries 20; 
mme, request, done( mme, req); 
return; 
| else if( host -> reqs. blocked) 
host -> reqs. blocked 20; 
WARN. ON( host -> mrq! = NULL) ; 
// WR B P li C EAE 


host -> mrq = req; 











/这 里 做 数据 的 准备 工作 ,如 果 有 数据 操作 ,会 对 DMA 进行 初始 化 ， 
// 并 启动 DMA channel ,在 需要 进行 DMA 传输 时 控制 器 会 发 送 request 信号 








// 开 始 实际 的 传输 ,这 是 硬件 自动 完成 的 
err = omap_hsmmc_prepare_data( host, req) ; 
if( err) | 

req -> cmd -> error = err; 

if( req -> data) 

req —> data —» error = err; 
host -> mrq = NULL; 
mme. request, done( mme, req); 


return ; 


| 
// 总 线 控制 器 启动 总 线 传输 


omap_hsmmc_start_command(host, req -> cmd, req —> data) ; 




















从 中 可 见 ， 主 要 是 进行 操作 前 的 准备 工作 ， 如 果 有 数据 传输 操作 ， 则 需要 在 函数 omap_ 
hsmmc_prepare_data 中 进行 DMA 申请 、 配 置 、 启 动 等 完成 相关 的 准备 工作 ， 剩 下 的 就 是 等 





待 硬件 信号 来 完成 数据 部 分 的 操作 。 














总 线 控制 器 的 传输 启动 操作 是 通过 omap_hsmmc _start_command 来 实现 的 ， 详 细 分 析 


如 下 : 


static void 


omap_hsmmc_start_command( struct omap_hsmmc_host * host, struct mme, command * cmd, 
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struct mmc, data * data) 


int emdreg 20, resptype 20, cmdtype =0 


dev. dbg( mme, dev( host -> mme) , " 96s; CMD%d, argument 0x96 08x Wn" , 
mmc, hostname( host -> mmc) , cmd -> opcode, cmd —» arg) ; 

/操作 命令 

host -> cmd = cmd; 

// 使 能 中 断 


omap_hsmmc_enable_irq( host, cmd) ; 





host -> response, busy =0; 
// 根 据 命令 类 型 中 的 标记 进行 总 线 设备 响应 类 型 等 参数 的 设置 
if(emd —> flags & MMC_RSP_PRESENT) | 
if( cmd —> flags & MMC_RSP_136) 
resptype =1; 
else if( cmd —> flags & MMC RSP BUSY)| 
resptype 23; 
host —» response, busy 21; 
| else 


resptype 22; 


if( cmd == host -> mrq —» stop) 

cmdtype = 0x3; 
// DEAS 8 FE d TELS SEAS BCE, CEPR AE PP til dit OE WE IS Pd DE E 
cmdreg = (cmd -> opcode << 24) | (resptype << 16) | ( emdtype <<22) ; 
/如 果 有 数据 传输 进行 相应 的 设置 
if( data) | 

emdreg | = DP. SELECT | MSBS | BCE; 

if( data -> flags & MMC, DATA, READ) 

emdreg |= DDIR; 





else 
emdreg & = ~ (DDIR) ; 

} 
/如 果 使 用 DMA 则 进行 属性 设置 ,保证 控制 器 可 以 发 送 DMA 请 求 信号 
if( host -> use, dma) 

cmdreg |  DMA. EN; 
// 记 录 控 制 带 在 处 理 状态 
host —» req. in. progress = 1 ; 
// 写 寄存 器 开始 操作 
OMAP_HSMMC_WRITE( host -> base, ARG, cmd -> arg) ; 
OMAP_HSMMC_WRITE( host -> base, CMD, cmdreg) ; 
































主要 是 根据 传输 的 命令 以 及 状态 进行 寄存 器 设置 。 接 下 来 控制 器 会 根据 操作 执行 的 情况 

ERPB, HF Ah BH PAZ. omap_hsmme_irq 会 进行 状态 的 检查 ， 根 据 状 态 做 必要 处 理 。 如 进 
行 数据 操作 时 有 错误 ， 则 需要 进行 必要 的 DMA 清理 ， 最 终 通过 mmc -equest- done 来 向 MMC 

ae mme request 的 操作 完整 状态 信息 都 在 mme, request 中 。 这 样 就 完成 了 整个 的 传 
输 操作 。 

3. card 状态 变化 

MMC 总 线 设备 有 插 拔 的 可 能 ， 这 就 需要 能 够 检测 设备 的 状态 ， 下 面 来 看 看 具体 如 何 实 

。 在 初始 化 时 ， 已 经 见 到 一 个 检测 相应 信号 的 中 断 ， 当 卡 的 状态 发 生变 化 时 会 有 中 断 产 

， 在 实现 中 由 omap_hsmme_cd_handler PEF 了 人 处理， 具体 如 下 . 


























// 该 函数 在 kernel 中 提供 card detect 的 处 理 , 对 于 该 handler FEL chip 的 

//mmce controller 通过 单独 GPIO irq 处 理 , 某 些 chip 通过 mme controller 的 
// 统 一 irq 检测 调用 。 具 体 和 chip 相关 ,在 没有 单独 的 GPIO 作为 card detect 的 
//chip 如 dm816x 通过 mmc 统一 的 irq handler 中 调用 该 handler 完成 后 续 处 理 


static irqreturn_t omap_hsmmc_cd_handler(int irq, void * dev. id) 


| 



































struct omap_hsmmc_host * host = (struct omap_hsmmc_host * ) dev. id; 


if( host -> suspended ) 

return IRQ_HANDLED; 
// 这 里 主要 是 schedule card detect work ,该 work 为 omap_hsmmc_detect 
// TE probe PAL PS: 


schedule_work ( &host -> mme, carddetect, work ) ; 












































return IRQ _HANDLED; 
| 





可 见 通过 work 来 进行 延迟 操作 ， 具 体 分 析 如 下 : 





// 通 过 work 的 方式 检查 并 通知 mme core, card insert 事件 该 函数 作为 work 的 
//function 等 待 schedule 调度 ,优点 是 延 时 调用 mmc, detect, change 以 避免 
// 不 完整 insert/remove 等 操作 
static void omap, hsmme, detect( struct work, struct. * work) 
| 
struct omap_hsmmc_host * host = 
container of( work, struct omap, hsmme, host, mmc_carddetect_work ) ; 
struct omap. mme. slot, data * slot = &mmce, slot( host) ; 


int carddetect ; 


if( host -> suspended ) 


return; 
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// 通 知 应 用 层 sysfs 的 poll 相应 属性 的 应 用 ,相应 的 属性 
// 发 生变 化 ,这 里 属性 变化 主要 是 说 明 card 的 拨 插 ,对 应 
// 于 kernel 开发 的 sysfs 属性 的 poll 功能 , 留 给 应 用 侦 测 接口 

sysfs_notify( &host -> mme -> class dev. kobj, NULL, "cover, switch" ) ; 






































// 如 果 slot 接口 有 card_detect, 则 说 明 有 GPIO 执行 通知 操作 
// 或 者 有 寄存 器 接口 查询 card detect 情况 


if( slot -> card_detect) 





carddetect = slot -> card_detect( host -> dev, host -> slot, id) ; 
else | 

// 如 果 没 有 card detect 操作 为 了 保护 card ,需要 进行 card 的 

J/ARAP ERLE ,避免 破坏 card 

omap. hsmme, protect, card( host) ; 


carddetect = — ENOSYS; 





// 388 Xll mme core 层 相 应 的 host 检测 到 变化 , 延 时 后 由 core 层 
// 进 一 步 检查 并 进行 后 续 操 作 
if( carddetect ) 

mme, detect, change( host -> mme, (HZ * 200) / 1000) ; 





else 


mme. detect, change( host -> mme, (HZ * 50) / 1000) ; 








主要 的 操作 就 是 获得 当前 卡 的 状态 ， 并 执行 mme_detect_change， 但 是 会 根据 状态 的 不 
同 进行 延 时 后 再 执行 设备 发 现 操作 。 
具体 的 卡 状态 检测 由 omap_hsmme_card_detect 来 执行 ， 具体 分 析 如 下 : 








//card detect 的 平台 接口 函数 ,主要 是 作为 平台 的 card detect 接口 函数 

// 注 册 为 相应 host slot 接口 的 card. detect 接口 进行 调用 ,由 schedule work 
//omap_hsmmc_detect 国 数 调用 . 该 函数 返回 card detect 的 状态 ,通过 这 里 
// 的 延 时 检查 保证 不 会 有 jitter 的 问题 

static int omap. hsmme, card, detect( struct device * dev, int slot) 


| 






































struct omap_mmc_platform_data * mmc = dev —> platform, data; 
struct omap_hsmmc_host * host = 


platform, get, drvdata( to. platform device( dev) ) ; 


// iR Hl card detect 的 状态 
if( mme -> version! = MMC CTRL VERSION 2) 
/ * NOTE: assumes card detect signal is active — low */ 


return! gpio, get. value, cansleep ( mmc —> slots[ 0 ]. switch, pin) ; 
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else | 
u32 pstate 20; 
u32 enabled 20; 
// 这 里 是 dm81xx 芯片 使 用 的 mme controller ip 




















enabled = host -> mme —> enabled; 
// WIRE enable, 26 enable 才能 读 取 寄存 需 
if( ! enabled) 


mmo, host. enable( host -> mmc) ; 


pstate = OMAP. HSMMC, READ( host -> base, PSTATE) ; 


// 保 证 读 取 状态 寄存 器 后 恢复 controller 的 状态 
if( ! enabled) 
mmo, host. disable( host -> mmc) ; 
printk ( " PSTATE 96 x Vn" , pstate) ; 
pstate = pstate & PSTATE CINS MASK ; 
pstate = pstate >> PSTATE CINS SHIFT; 





return pstate ; 


这 样 整个 状态 变化 的 操作 就 完整 了 。 
7.3.4 MMC 电源 管理 相关 说 明 


对 于 MMC 整体 的 电源 管理 ， 首 先 来 看 总 线 部 分 ， 在 mmc_bus_type 中 与 电源 管理 相关 的 
操作 接口 如 下 : 


static struct bus. type mme, bus type = | 


. suspend = mmc, bus suspend, 

. resume - mme, bus, resume, 

.pm = MMC, PM OPS PTR, 
ls 


可 见 其 中 实现 了 SLM 以 及 runtime pm 的 接口 。SLM 以 suspend 操作 为 例 ， 细 市 如 下 : 


static int mme, bus, suspend( struct device * dev, pm. message t state) 


struct mme, driver * drv = to mme. driver( dev —> driver) ; 


struct mme, card. * card = mme. dev, to. card( dev) ; 
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int ret =0; 


if( dev -> driver && drv —> suspend) 
ret = drv -> suspend( card, state) ; 


return ret; 


| 








可 见 主 要 是 执行 驱动 的 suspend 操作 ， 在 MMC 框架 中 就 是 mmeblk 驱动 ， 相 应 的 接口 是 





mmc_blk_suspend， 其 中 实际 的 操作 就 是 通过 blk_stop_queue 来 停止 接收 块 操作 请 求 。 





以 runtime suspend 的 接口 为 例 讲解 runtime pm 的 接口 。 在 MMC 框架 中 接口 是 mmc_runt- 
ime_suspend ， 其 会 通过 mme, power, save, host 来 调用 mmc, bus, ops 中 的 power, save 接口 ， 进 
行 runtime pm 的 操作 。 实 际 中 power_save 接口 并 没有 进行 设置 。 





另外 在 实际 操作 过 程 中 为 了 减少 功 耗 ，MMC 框架 提供 


Lf mme. host. enable 和 mme _ 





host disable 接口 ， 用 于 总 线 控制 器 的 电源 管理 操作 ， 在 需要 时 enable， 不 需要 时 disable, 
这 样 可 以 降低 控制 器 的 功 耗 ， 而 mmc. host ops 中 需要 提供 enable 和 disable 接口 进行 相应 





的 操作 。 


总 线 控制 右 的 电源 管理 操作 ， 主 要 是 由 platform driver 提供 的 。DM 3730 的 MMC 总 


制 器 相应 的 操作 如 下 : 


static struct dev. pm, ops omap_hsmmc_dev_pm_ops = | 





. suspend = omap. hsmmce, suspend , 
. resume -omap hsmmce resume, 


E 
以 suspend 操作 为 例 进 行 分 析 ， 细 节 如 下 : 


static int omap. hsmme, suspend( struct device * dev) 
int ret 20; 


struct platform, device * pdev = to, platform, device( dev) 








, 


struct omap. hsmme, host * host = platform, get. drvdata( pdev ) ; 


if( host && host -> suspended) 
return 0; 
if( host) | 
// XE ^. suspend 状态 
host -> suspended = 1 ; 
// 这 里 如 果 card detect 是 GPIO 实现 , 则 需要 清 弄 
if( host -> pdata —» suspend) | 





,并 做 必要 的 处 理 


ret = host -> pdata —» suspend( &pdev -> dev, host -> slot. id) ; 
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线 控 


// SUF card detect 相关 操作 

cancel work, sync( &host -> mmc_carddetect_work ) ; 

// 进 行 MMC 层面 的 总 线 控制 器 suspend 操作 ,这 里 是 执行 bus ops 

// 中 的 suspend 操作 ,不 同 的 规范 操作 不 同 ,主要 是 设置 状态 ,对 于 SDIO 
// 则 会 执行 驱动 的 suspend 操作 


ret = mmc_suspend_host( host -> mmc) ; 












































mmc_host_enable( host -> mmc) ; 
if( ret ==0) | 
omap. hsmme. disable irq( host) ; 
// 切 断 bus power 
OMAP_HSMMC_WRITE(host -> base, HCTL, 
OMAP_HSMMC_READ(host —» base, HCTL) & ~ SDBP); 
mmo, host. disable( host -> mmc) ; 
clk_disable( host -> iclk ) ; 
if( host -> got. dbelk ) 
clk_disable( host -> dbelk ) ; 
| else | 
// 之 前 操作 失败 则 恢复 
host -> suspended =0; 
if( host — > pdata —» resume) | 
ret = host -> pdata — > resume( &pdev -> dev, 
host —> slot. id) ; 
if( ret) 
dev. dbg( mme, dev( host -> mmc) , 
" Unmask interrupt failed Wn" ) ; 
} 


mmc_host_disable( host -> mmc) ; 


return ret; 


| 
可 见 不 仅 对 总 线 进行 了 具体 操作 1 还 将 总 线 的 power 切断 ， 做 得 还 是 很 彻底 的 。 
这 样 MMC 总 线 的 电源 管理 部 分 就 基本 完整 了 。 


7.4 通用 串 行 总 线 (USB) 


7.4.1 USB 总 线 驱 动 需求 

USB (Universal Serial Bus) 是 连接 计算 机 系统 与 外 部 设备 的 一 种 串口 总 线 标准 ， 也 是 一 
种 输入 输出 接口 的 技术 规范 ， 被 广泛 地 应 用 于 个 人 电脑 和 移动 设备 等 通信 产品 ， 并 扩展 至 摄 
影 融 材 、 数 字 电 视 ( 机顶盒 ) 、 游 戏 机 等 其 他 相关 领域 。 
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USB 最 初 是 由 英特尔 公司 与 微软 公司 倡导 发 起 的 ， 其 最 大 的 特点 是 支持 热 插 拔 和 即 插 即 
用 。 当 设备 插入 时 ， 主 机 枚 举 到 此 设备 并 加 载 所 需 的 驱动 程序 ， 使 用 比 其 他 总 线 方便 。 在 速度 
方面 ，USB 1. 1 的 最 大 传输 带宽 为 12 Mbit/s, USB 2.0 的 最 大 传输 带宽 为 480 Mbit/s, USB 3.0 
的 最 大 传输 带宽 为 Gbit/s. 

USB 的 设计 为 非 对 称 式 的 ， 它 是 主 从 式 总 线 ， 任 何 USB 事务 都 是 由 主机 引发 的 。USB 
主机 处 于 主 模式 ， 设 备 处 于 从 模式 。USB 总 线 是 由 主机 控制 器 和 若干 hub 设备 以 及 与 hub 连 
接 的 从 设备 组 成 的 。USB 总 线 拓扑 如 图 7-12 所 示 。 图 7-12 引 自 《USB2. 0 规范 》。 








图 7-12 USB 总 线 拓扑 


从 图 7-12 可 见 ， 一 个 Host 控制 器 会 和 root hub 绑 定 ， 并 可 以 通过 Hub 连接 多 个 设备 。 

USB 可 以 连接 的 外 设 有 鼠标、 键盘 、 游 戏 手柄 、 游 戏 杆 、 扫 描 仪 、 数 码 相 机 、 打 印 机 、 
硬盘 和 网 络 部 件 等 各 种 设备 。USB 总 线 已 经 成 为 使 用 最 广泛 的 设备 连接 标准 。 

规范 中 为 了 实现 以 上 的 功能 对 总 线 中 的 很 多 环节 都 进行 了 定义 。 一 个 USB 物理 设备 可 
以 承担 多 种 功能 ，USB 的 术语 中 设备 (device) 指 的 是 功能 (functions) ， 更 注重 逻辑 性 。 规 
范 中 关于 主 从 设备 的 交互 如 图 7-13 所 示 。 


Client 
Software 








Communication 
Flows 






Interface 


图 7-13 USB 主 从 设备 交互 框图 
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从 图 7-13 可 见 ， 管 道 (pipe) 把 主机 控制 器 和 端点 (endpoint) 连接 起 来 形成 一 个 交 
互通 道 进行 主 从 设备 的 交互 。 端 点 只 能 单 向 〈 进 /出 ) 传输 数据 ， 管 道 也 是 单 向 的 。 每 个 
USB 设备 至 少 有 两 个 端点 /管道 ， 分 别 是 进 和 出 两 个 方向 ， 编 号 为 0， 用 于 控制 总 线 上 的 设 
备 。 按 照 各 自 的 传输 类 型 ， 管 道 被 分 为 4 类. 

e 控制 传输 〈Control) 。 一 般 用 于 短 的 、 简 单 的 设备 命令 和 状态 反馈 ,例如 用 于 总 线 控 

制 的 0 号 管道 。 
e 同步 传输 (Isochronous) 。 按 照 有 保障 的 速度 传输 ， 可 能 有 数据 丢失 ， 例 如 实时 的 音 














频 和 视频 。 
e 中 断 传输 (Interrup) 。 用 于 必须 保证 尽快 反应 的 设备 (有 限 延 迟 ) ， 例 如 鼠标 和 
键盘 。 














e 批量 传输 (Bulk)。 使 用 余下 的 带宽 大 量 地 (但 是 没有 对 于 延迟 、 连 续 性 、 带 宽 和 速 
度 的 保证 ) 传输 数据 ， 例 如 普通 的 文件 传输 。 

为 了 访问 端点 ， 必 须 获得 设备 一 个 分 层 的 配置 。 连 接 到 主机 的 设备 只 有 一 个 设备 描述 符 
(device descriptors) ， 而 设备 描述 符 有 若干 配置 描述 符 (configuration descriptors) 。 这 些 配置 
一 般 与 状态 相对 应 ,例如 活跃 季 能 模式 。 每 个 配置 描述 符 有 阁 干 接口 描述 符 (interface 
setting) ， 用 于 描述 设备 的 一 个 功能 方面 ， 所 以 可 以 用 于 描述 从 设备 不 同 的 功能 ， 如 一 个 相 
机 可 能 拥有 视频 和 音频 两 个 接口 。 接 口 描述 符 有 一 个 默认 接口 设置 (default interface set- 
tings) 和 可 能 多 个 替代 接口 设置 (alternate interface settings) ， 接 口 设 置 中 包含 端点 描述 符 。 
一 个 端点 能 够 在 多 个 接口 和 替代 接口 设置 之 间 复 用 。 

总 体 上 来 说 ， 系 统 对 USB 总 线 驱 动 的 需求 就 是 要 能 按 规范 实现 总 线 的 各 种 功能 ， 并 且 
满足 总 线 的 各 种 无 关 性 的 需求 。 


7.4.2 USB 总 线 驱 动 框架 解析 


l. 总 线 相关 以 及 核心 框架 
针对 USB 功能 ，Linux 内 核 中 提供 了 主 设备 和 从 设备 两 个 不 同 的 框架 ， 这 里 主要 介绍 作 
为 主 设备 的 框架 。USB 总 线 主 设备 框架 还 是 以 bus_type 作为 人 口 来 了 解 总 线 框架 。 






































struct bus type usb, bus type = | 


.name = "usb" , 

. match = usb_device_match, 

. uevent = usb_uevent, 
#ifdef CONFIG_USB_SUSPEND 

. pm = &usb_bus_pm_ops, 
#endif 


区 





usb. bus type 中 重要 的 是 usb_device_match, ， 下 面 来 了 解 细节 : 


static int usb_device_match( struct device * dev, struct device_driver * drv) 


/ * devices and interfaces are handled separately * / 
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// 对 device 进行 区 分 
if(is_usb_device(dev) ) | 
// 这 里 表明 是 usb device 
/ * interface drivers never match devices * / 
// 检 查 驱 动 是 否 对 应 于 usb device 
if( ! is_usb_device_driver( drv) ) 
return 0; 
return 1; 
| else if(is usb. interface( dev) ) | 
// 这 里 是 usb interface 
struct usb, interface * intf; 
struct usb, driver * usb_drv; 


const struct usb, device id * id; 


/ * device drivers never match interfaces * / 
if(is usb. device, driver( drv) ) 

return 0; 
// 这 里 驱动 和 设备 类 型 是 匹配 的 


intf = to_usb_interface( dev) ; 





usb_drv = to, usb. driver( drv) ; 
/进行 真正 的 匹配 ,匹配 ID 表 
id =usb_match_id(intf，usb_drv —» id. table) ; 
if(id) 

return 1; 
// Ve Bal a ID 
id = usb. match, dynamic, id( intf, usb, drv) ; 
if( id) 


return 1; 








| 
return 0; 


| 





从 分 析 中 可 知 ，USB 总 线 框架 主要 管理 的 是 两 类 设备 ， 分 别 是 usb_device 和 usb_inter- 
face, M USB 规范 的 角度 可 知 usb. interface 更 专注 于 功能 ， 应 该 是 获得 描述 符 之 后 才 创 建 
的 ， 而 usb device 则 对 应 于 USB 物理 设备 。 这 样 就 从 人 逻辑 功能 和 物理 层面 都 对 设备 进行 管 
理 ， 从 管理 层次 上 来 说 也 是 完整 的 。 对 应 的 驱动 包括 usb_device_driver 和 usb_driver， 其 中 
usb_device_driver 对 应 于 usb_device， 而 usb_driver 则 对 应 于 usb_interface。usb_device_driver 
主要 用 于 实现 设备 发 现 ， 而 usb driver 则 主要 实现 与 功能 模块 的 关联 以 及 电源 管理 相关 的 
功能 。 

像 其 他 总 线 设备 一 样 ， 总 线 控制 器 负责 总 线 事务 的 交互 。USB 主 设 备 总 线 框架 就 是 对 
以 上 内 容 的 管理 ， 具 体 架 构 如 图 7-14 所 示 。 
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Client Software 





Host System Software 





USBDI 


Al7-14 Linux USB 主 设 备 总 线 架 构 


从 图 7-14 可 见 ，USB 总 线 框架 各 模块 划分 ， 包 括 host software 主要 负责 协议 相关 的 部 
分 ， 包 括 枚 举 设 备 、 数 据 传 输 等 ，USBDI (USB driver interface) 主要 负责 屏蔽 USB 细节 , 
为 其 他 功能 框架 使 用 USB 总 线 传输 的 接口 层 ，USBD ( 即 USB driver) 负责 USB 设备 的 功能 
关联 ; HCDI 则 是 屏蔽 不 同 总 线 控 制 器 之 间 的 差别 ; 最 后 Host Controller Driver 是 具体 的 总 线 
控制 器 的 驱动 ， 相 应 地 负责 与 总 线 控制 器 交互 完成 总 线 传 输 。 

这 样 整体 框架 从 层次 的 角度 就 完整 了 。 


2. 











总 线 控制 器 相关 


USB 总 线 框架 对 总 线 控制 器 的 管理 主要 是 通过 usb_hcd 来 实现 的 ， 其 详细 分 析 如 下 : 





struct usb_hcd | 





// 总 线 控制 器 所 管理 的 总 线 信息 ,其 中 包含 总 线 编 号 以 及 root hub 的 信息 








struct usb_bus self; / * hed is—a bus */ 

struct kref kref; / * reference counter * / 
const char * product, desc; / * product/vendor string * / 
char irq_descr[ 24]; /* driver + bus # */ 


//root hub 需要 的 timer 
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struct timer_list rh_timer; / * drives root — hub polling * / 


// 通 常 为 root hub 的 状态 urb. 用 于 设备 发 现 

















struct urb * status_urb; / * the current status urb * / 
#ifdef CONFIG. USB. SUSPEND 

struct work. struct wakeup. work ; / * for remote wakeup * / 
#endif 











//omap3 的 work 操作 用 于 电源 管理 
struct work_struct ehci_omap_work ; 
// 总 线 传输 的 操作 接口 

const struct hc, driver * driver; /* hw-specific hooks */ 
/总 线 控制 恬 的 各 种 属性 


unsigned long flags ; 














au 








/ * Flags that get set only during HCD registration or removal. */ 








// 各 种 特性 信息 

unsigned rh_registered:1;/ * is root hub registered? */ 
unsigned rh. pollable :1 ; / * may we poll the root hub? * / 
unsigned uses new. polling:1; 

unsigned wireless :1 ; / * Wireless USB HCD * / 
unsigned authorized. default :1 ; 

unsigned has tt:1; / * Integrated TT in root hub */ 
// 分 配 的 中 断 

int irq; / * irg allocated * / 

// AR RACE BY es e SH 

void __iomem * regs; / * device memory/io */ 
u64 rsrc, start ; / * memory/io resource start * / 
u64 rsrc. len; / * memory/io resource length * / 
unsigned power budget; /** in mA, O0 z no limit */ 
struct mutex bandwidth, mutex ; 

/缓冲 空间 

struct dma_pool * pool| HCD_BUFFER_POOLS ] ; 

// 状 态 

int state; 


// 为 不 同类 型 的 总 线 控制 器 分 配 的 空间 
unsigned long hed_priv[0 | __attribute__( ( aligned( sizeof( unsigned long) ) ) ) ; 
ic 





从 管理 实体 中 可 见 ， 其 中 除了 自身 的 属性 和 状态 之 外 还 包含 了 root hub 相关 的 信息 ， 这 
与 硬件 及 规范 一 致 。 另 外 重要 的 就 是 he_driver， 其 中 包含 实际 操作 的 接口 ， 负 责 总 线 传输 。 
由 于 USB 总 线 控制 器 有 不 同 的 类 型 ， 如 OHCI, EHCI, UHCI, XHCI 等 ， 这 里 usb hed 是 对 
所 有 这 些 总 线 控制 器 共性 的 抽象 ， 相 应 的 hed. priv 指向 不 同 控制 器 私有 的 属性 ， 主 要 是 定义 
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不 同 的 传输 排列 方式 以 及 控制 状态 寄存 器 等 。 这 里 与 其 他 总 线 控制 器 实体 不 同 的 是 没有 设备 
模型 的 实体 ， 主 要 是 由 于 USB 总 线 控制 器 与 root hub 的 亲密 关系 ， 而 root hub 本 身 就 是 设 
备 ， 而 设备 的 层次 关系 通过 usb_bus 中 的 controller 进行 关联 。 

关于 总 线 控制 器 ，USB 框架 提供 了 创建 以 及 注册 管理 的 接口 。 首 先 来 了 解 创建 的 接口 


usb_create_hcd : 























struct usb_hcd * usb_create_hcd(const struct hc_driver * driver, 


struct device * dev, const char * bus name) 


struct usb hed * hed; 
/分 配 控 制 器 的 整体 空间 ,包括 公共 的 hed 空间 和 具体 总 线 控制 器 的 私有 空间 ， 
// 私 有 空间 的 大 小 由 he; driver 中 的 hed. priv. size 来 定义 
hed = kzalloc(sizeof( * hed) + driver -> hed, priv. size, GFP. KERNEL) ; 
if( ! hed) | 
dev. dbg( dev, "hed alloc failed n" ) ; 
return NULL; 











} 

dev_set_drvdata(dev, hed) ; 

kref_init( &hed -> kref) ; 

// 初 始 USB 总 线 以 及 相关 信息 

usb_bus_init( &hed -> self) ; 

hed -> self. controller = dev; 

hed -> self. bus_name = bus_name; 

hed -> self. uses_dma = (dev -> dma_mask! = NULL) ; 

// 初 始 root hub 定时 操作 等 信息 

init, timer( &hed -> rh, timer) ; 

hed -> rh, timer. function = rh. timer, func ; 

hed -> rh. timer. data = (unsigned long) hed; 
#ifdef CONFIG. USB SUSPEND 

INIT WORK( &hed -> wakeup. work, hed resume. work ) ; 
#endif 

mutex, init( &hed -> bandwidth, mutex ) ; 

/设置 总 线 操作 接口 

hed -> driver = driver; 

hed -> product, desc = ( driver -> product, desc) ? driver -> product, desc : 

"USB Host Controller" ; 


/ * ehci omap specific * / 
if( hed -> driver — > recover. hed ) 
INIT WORK( &hed ->ehci_ omap. work, hed -> driver -> recover hed); 


return hed; 
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从 分 析 中 可 见 ，USB 总 线 控制 器 的 操作 已 经 与 USB 总 线 以 及 root hub 的 操作 相 结合 ， 这 


与 它们 之 间 的 紧密 关系 是 分 不 开 的 。 





对 于 注册 与 管理 接口 ，USB 框架 的 接口 为 usb_add_hcd， 主 要 功能 是 初始 化 并 注册 总 线 
控制 器 ， 其 中 同样 包括 注册 USB 总 线 以 及 创建 并 注册 root hub。 在 调用 了 usb_add_hed 时 ， 
就 创建 了 总 线 ， 从 而 可 以 进行 设备 发 现 以 及 驱动 功能 绑 定 的 工作 。 

框架 提供 了 统一 的 传输 以 及 其 他 总 线 控制 器 功能 操作 接口 ， 具 体 如 下 : 











int usb_hed_submit_urb( struct urb * urb, gfp_t mem_flags) ; 


int usb_hcd_unlink_urb( struct urb * urb, int status) ; 


void usb hed giveback urb(struet usb_hed * hed, struct urb * urb, int status) ; 


void unmap_urb_setup_for_dma( struct usb_hed * , struct urb * ) ; 


void unmap. urb. for dma( struct usb_hed * , struct urb * ) ; 


void usb hed flush, endpoint( struct usb, device * udev, struct usb. host, endpoint * ep); 


void usb hed disable endpoint( struct usb, device * udev, struct usb. host, endpoint * ep); 


void usb hed reset endpoint(struct usb. device * udev, struct usb. host, endpoint * ep); 


void usb hed synchronize unlinks( struct usb, device * udev) ; 


int usb_hed_alloc_bandwidth( struct usb, device * udev, struct usb, host, config * new, config, 


struct usb, host, interface * old alt, struct usb, host, interface * new. alt) ; 


int usb. hed. get. frame number( struct usb. device * udev) ; 








这 样 总 线 控制 器 的 底层 与 上 层 就 完整 了 。 


3. 总 线 设 备 相关 
USB 设备 在 总 线 框架 中 已 经 有 所 介 
来 了 解 usb. device 的 详细 信息 : 








struct usb_device | 
// irte DRIT BOR Hk 
int devnum ; 
/完整 的 路 径 
char devpath| 16 ] ; 





绍 ， 


主要 由 usb. device 和 usb. interface 共同 完成 。 先 


// 表 示 如 何 找到 设备 ,其 中 包含 通过 hub 以 及 port 到 达 设 备 


u32 route ; 


























enum usb. device. state state; 
// 速 度 类 型 
enum usb_device_speed speed; 


//hub HFA RRAPI tit on [o] Pe R 





struct usb, tt * tt; 


int ttport ; 


unsigned int toggle[ 2 ] ; 





// 指 向 设备 所 在 hub ,如 果 是 root hub 这 里 为 空 
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struct usb_device * parent; 

// PEE bus ,其 中 包含 root hub 信息 
struct usb bus * bus; 

// Ti Wild endpoint 


struct usb host, endpoint ep0; 








// 设 备 模型 相关 

struct device dev; 

// 描 述 符 

struct usb_device_descriptor descriptor; 
// ME 

struct usb. host, config * config; 

// 当 前 设置 的 配置 

struct usb. host, config * actconfig; 
// 所 有 的 endpoint 信息 
struct usb_host_endpoint * ep_in[ 16]; 





struct usb, host, endpoint * ep out[ 16] ; 
/原始 的 描述 符 信 息 


char * * rawdescriptors ; 





/需要 的 电流 

unsigned short bus mA ; 
// 所 在 hub 的 端口 
u8 portnum; 

// 所 在 物理 连接 的 层 数 
u8 level; 
/状态 信息 


unsigned can, submit :1 ; 























unsigned persist, enabled :1 ; 

unsigned have, langid :1 ; 

unsigned authorized : 1 ; 

unsigned authenticated :1 ; 

unsigned wusb:1; 

int string langid ; 

/ * static strings from the device * / 
// 设 备 信息 


char * product; 





char * manufacturer; 


char * serial; 
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从 分 析 中 可 见 ， 总 线 规范 中 关于 设备 的 各 种 属性 都 在 usb. device 中 有 了 体现 。 再 来 看 看 
interface 的 管理 实体 : 





struct usb_interface | 
// 可 选 的 interface 属性 
struct usb, host, interface * altsetting; 
// 当 前 的 interface 属性 


struct usb_host_interface * cur altsetting; / * the currently active alternate setting * / 


rl 








E 


unsigned num. altsetting; / * number of alternate settings * / 


struct usb_interface_assoc_descriptor * intf_assoc; 


// WER interface 直接 针对 功能 设备 ,这 里 表示 usb class 的 子 设备 号 











int minor; / * minor number this interface is bound to * / 
enum usb, interface. condition condition ; / * state of binding */ 
// 属 性 信息 

unsigned sysfs_files_created :1 ; / * the sysfs attributes exist * / 
unsigned ep_devs_created;1; / * endpoint "devices" exist * / 
unsigned unregistering: 1 ; / * unregistration is in progress * / 
unsigned needs remote, wakeup:1; / * driver requires remote wakeup * / 
unsigned needs altsettingO :1 ; / * switch to altsetting 0 is pending */ 
unsigned needs binding: ; / * needs delayed unbind/rebind * / 
unsigned reset, running:1 ; 

unsigned resetting device:1; /* true: bandwidth alloc after reset * / 
/设备 模型 相关 

struct device dev; / * interface specific device info * / 


// TX] interface 直接 对 应 用 开放 的 功能 ,相应 的 为 class 类 型 设备 


struct device * usb dev; 





atomic t pm usage cnt; / * usage counter for autosuspend * / 


struct work, struct reset, ws; / * for resets in atomic context * / 


E 


usb, interface 会 在 枚 举 时 创建 usb_host_interface ， 其 中 包含 了 endpoint 的 信息 ， 这 与 总 线 
规范 是 一 致 的 ， 另 外 通过 interface_to_usbdev 可 以 关联 到 usb. device (通过 dev 的 parent 关联 
的 ) ， 这 样 设备 层面 就 都 关联 在 一 起 了 。 

总 线 设备 最 重要 的 功能 就 是 设备 发 现 ，USB 总 线 的 设备 发 现 流程 如 图 7-15 所 示 。 

这 里 主要 是 hub 的 功能 ， 最 终 会 通过 usb new. device 来 将 usb. device 注册 进 系统 ， 相 
应 的 usb device 是 通过 usb_alloc_dev 进行 分 配 的 ， 在 usb new. device 中 会 读 取 描述 符 ， 在 
注册 之 后 就 会 进行 对 应 设备 驱动 的 match 工作 。 在 总 线 框架 中 可 知 ，usb_device 直接 返回 
的 值 为 1， 这 是 由 于 系统 中 只 有 一 个 对 应 于 usb, device 的 驱动 ， 即 usb_generic_driver， 细 
TA: 
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Host Controller Hardware HCD khubd core bus layer 







2usb hod poll rh satus 
3:kick_khubd 


1.Reset the device 
2.Get Device Desccriptor 
3.Set Device Address 


1.Get Configuration Descriptor. 
2.Get Interface Descriptors i 
3.Get Endpoint Descriptors. 10:bus_attach_device 
4.Parse the descriptor information. 11:bus_for_each_drv 






12:Driver_probe 


图 7-15 Linux USB 设备 发 现 流程 





struct usb_device_driver usb_generic_driver = | 
. name = "usb" , 
. probe = generic, probe, 
. disconnect = generic, disconnect , 
#ifdef CONFIG_PM 
. suspend = generic_suspend , 
. resume = generic_resume , 
#endif 


. supports_autosuspend =1, 


接 下 来 设备 发 现 的 功能 由 generic probe 实现 ， 下 面 来 看 看 细节 : 





static int generic probe( struct usb, device * udev) 


| 


int err, c; 


if( usb. device, is owned( udev) ) 


; /** Don t configure if the device is owned * / 
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行 管 
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else if( udev -> authorized ==0) 
dev_err( &udev -> dev, "Device is not authorized for usage Wn" ) ; 
else | 
// 这 里 主要 是 进行 选择 配置 ,并 进行 配置 的 操作 
c = usb. choose, configuration( udev) ; 
if( c >=0) | 
err = usb. set. configuration( udev, c) ; 
if( err) | 
dev. err( &udev -> dev, "cad t set config #%d, error % d\n", c, err) 





} 
/ * USB device state == configured ... usable */ 


// 已 经 配置 通知 其 他 系统 
usb_notify_add_device( udev) ; 




















return 0; 


| 





, 





这 里 主要 是 读 取 配置 信息 并 进行 配置 。 在 usb_set_configuration 中 会 根据 设备 的 属性 创 
建 所 有 的 usb. interface 并 注册 。 这 样 USB 系统 就 开始 对 功能 驱动 的 匹配 工作 ， 相 应 的 进入 到 
USB 总 线 match 工作 的 后 半 部 分 ， 即 usb_interface 相关 的 部 分 ， 找 到 相应 的 驱动 再 执行 
probe ， 从 而 完成 整个 设备 发 现 及 驱动 绑 定 的 功能 。 
4. 总 线 传输 接口 

















USB 总 线 传输 主要 是 实现 USB 总 线 规范 中 的 四 种 传输 ， 在 Linux USB 框架 中 通过 urb 进 
理 ， 主 要 内 容 如 下 : 
struct urb | 

/ * private: usb core and host controller only fields in the urb */ 

struct kref kref; / * reference count of the URB * / 

// Be RE IMAGE il i D) f E 

void * hepriv; / * private data for host controller * / 

/并 发 提交 次 数 

atomic_t use_count; / * concurrent submissions counter * / 

// 失 败 次 数 

atomic_t reject; / * submissions will fail * / 

int unlinked; / * unlink error code * / 

/ * public; documented fields in the urb that can be used by drivers * / 

//urb 链表 

struct list head urb list; / * list head for use by the urb s current owner * / 

struct list head anchor. list; / * the URB may be anchored * / 

struct list head giveback list ; / * to postpone the giveback call * / 


struct usb, anchor. * anchor; 


// 指 向 USB 设备 






































struct usb_device * dev; / * (in) pointer to associated device * / 
// 关 联 的 endpoint 

struct usb_host_endpoint * ep; / * (internal) pointer to endpoint * / 

// 针 对 总 线 规范 的 pipe 信息 

unsigned int pipe; / * (in) pipe information * / 

// 针 对 Bulk 

unsigned int stream_id; / * (in) stream ID */ 

int status; / * (return) non — ISO status * / 

人/ 表明 urb 如 何 被 提交 等 传输 属性 

unsigned int transfer_flags ; / * (in) URB. SHORT. NOT OK | ee RS 
// 相 关 的 输入 输出 buffer, 5j endpoint 输入 输出 属性 相关 

void * transfer buffer; / * (in) associated data buffer * / 
//DMA 操作 时 的 空间 ,驱动 可 在 transfer dma 与 transfer. buffer 之 间 选 择 
dma_addr_t transfer_dma; / * (in) dma addr for transfer. buffer * / 
// buffer 的 scatterlist 表 

struct scatterlist * sg; / * (in) scatter gather buffer list * / 

int num. sgs; / * (in) number of entries in the sg list * / 
// buffer 的 长 度 

u32 transfer buffer length; / * (in) data buffer length * / 

/实际 传输 的 长 度 

u32 actual_length; / * (return) actual transfer length * / 
unsigned char * setup_packet; / * (in) setup packet( control only) */ 
dma_addr_t setup_dma; / * (in) dma addr for setup_packet * / 
int start, frame; / * (modify) start frame( ISO) */ 

int number, of. packets ; / * (in) number of ISO packets * / 

int interval ; / ** (modify) transfer interval(INT/ISO) */ 
int error count; / * (return) number of ISO errors * / 
// 用 于 同步 的 参数 

void * context; / * (in) context for completion * / 

/人 同步 的 回调 

usb_complete_t complete ; / * (in) completion routine * / 


struct usb. iso. packet. descriptor iso. frame desc[ 0] ; / * (in) ISO ONLY */ 
E 





USB 总 线 的 传输 是 以 urb 为 核心 展开 的 。 具 体 的 流程 如 图 7-16 所 示 。 
为 了 简化 USB 总 线 传输 操作 ，USB 总 线 框架 提供 了 如 下 接口 以 实现 几 种 类 型 的 总 线 传 
输 功 能 : 





int usb_control_msg( struct usb. device * dev, unsigned int pipe, __u8 request, 


. u8 requesttype, _ ul6 value, _ ul6 index, void * data, _ ul6 size, int timeout) ; 
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Class Driver usbcore HCD 
1 
1 
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中 第 


H H 
1:usb_alloc_urb 









2:usb_init_urb 


3:return urb 


4 usb buffer alloc 5:hcd_buffer_alloc 


6:return 


7: return TS RH a 四 r 


8:usb fill XXX, urb 
9:usb submit urb 
10O:usb link urb 


11:usb hcd, submit urb 
13:return 


14:return 


19:usb unlink urb 


20|completion routine 
21:usb put urb 





Ez 18:usb_hcd_giveback_urb 


12:urb_enqueue 


re 一 一 一 一 - -- 2 eee ee ee ee eee re = == = = 













17:10 Completion Interrupt 





图 7-16 Linux USB 总 线 传输 流程 图 


Host Controller Hardware 


int usb, interrupt. msg( struct usb, device * usb dev, unsigned int pipe, void * data, int len, int 


* actual. length, int timeout) ; 


int usb. bulk msg(struct usb. device * usb dev, unsigned int pipe,void * data, int len, 


int * actual length, int timeout) ; 





USB 总 线 框架 已 经 为 主要 功能 都 提供 了 统一 的 操作 ， 
3 TI 芯片 USB 总 线 驱 动 相关 实现 详解 








并 提供 了 良好 的 接口 供 驱 动 开 发 。 


DM 3730 的 USB 主机 控制 器 框架 如 图 7-17 所 示 。 图 7-17 引 自 《DM 3730 芯片 手册 》 


3247 页 的 框图 。 
从 图 7-17 D DM 3730 中 包含 OHCI fll EHCI, 


以 EHCI 为 例 进行 介绍 。 
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1. 初始 化 











男 外 是 一 些 连 接 属性 的 配置 ， 





先 来 看 看 初始 化 部 分 ， 还 是 通过 platform driver 的 probe 也 数 来 了 解 细 节 ， 其 内 容 如 下 . 


这 里 
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d 7-17 DM 3730 USB 主机 控制 器 框架 图 





static int ehci hed omap. probe( struct platform. device * pdev) 
| 
struct ehci_hcd_omap_platform_data * pdata = pdev -> dev. platform. data; 
struct ehci_hcd_omap * omap; 
struct resource * res; 
struct usb_hed * hed; 
/获得 中 断 号 
int irq = platform. get. irq( pdev, 0) ; 
int ret = - ENODEV ; 
int 1; 


char supply[ 7 ] ; 


if( usb. disabled( ) ) 
goto err disabled; 
// 分 配 设备 相关 的 管理 实体 
omap = kzalloc( sizeof( * omap) , GFP_KERNEL) ; 
if( ! omap) | 
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ret = - ENOMEM; 
goto err disabled ; 








// 创 建 总 线 控制 器 ,其 中 包含 EHCI 管理 实体 的 空间 
ghed = hed = usb_create_hed( &ehci_omap_hc_driver, &pdev -> dev, 








dev. name( &pdev -> dev) ) ; 








// 设 置 设备 相关 信息 

platform, set. drvdata( pdev, omap) ; 

omap —> dev = &pdev —> dev; 

omap — » phy. reset = pdata -> phy. reset ; 

omap —> reset, gpio. port[ 0 | = pdata —> reset, gpio. port[ 0 ] ; 
omap — reset, gpio. port[ 1 ] = pdata -> reset, gpio. port[ 1 ] ; 
omap — reset, gpio. port| 2 | = pdata -> reset, gpio. port[ 2 | ; 
omap — port_mode| 0 | = pdata -> port, mode[ 0] ; 
omap -> port_mode| 1 | = pdata -> port, mode[ 1 ] ; 
omap — port, mode| 2 | = pdata -> port, mode[2 ] ; 
omap —» ehci = hed. to. ehei( hcd); 

omap —> ehci -> sbrn 20x20; 


omap — > suspended 20; 


// i Ae Ps AF SMILIES [8] 

res = platform_get_resource( pdev, IORESOURCE MEM, 0) ; 
hed -> rsre, start = res 一 > start; 

hed -> rsre, len = resource, size( res) ; 

// 进 行 相 应 空间 的 映射 


hed -> regs = ioremap( hcd —» rsre, start, hed ->rsrc_len ) ; 


/ * we know this is the memory we want, no need to ioremap again * / 
// EHCI 的 基本 能 力 寄存 带 

omap -> ehci -> caps = hed -> regs; 

//EHCL 的 寄存 器 基地 址 


omap — > ehci_base = hcd —> regs; 


/ * get ehci regulator and enable * / 
// 每 个 端口 的 物理 电源 初始 化 
for(i=0 ; i<OMAP3_HS_USB_PORTS ; i++)! 
if( omap -> port, mode[ i]! = EHCILHCD_OMAP_MODE_PHY) | 
omap -> regulator[ i] = NULL; 





























continue ; 
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snprintf( supply, sizeof( supply), "hsusb96 d" , i); 
omap -> regulator[ i] = regulator get( omap -> dev, supply) ; 
if( IS ERR(omap -> regulator[ i] ) ) | 
omap -> regulator[ i] = NULL; 
dev. dbg( &pdev -> dev, 
"failed to get ehci port% d regulator Vn" , i); 
| else | 


regulator enable( omap -> regulator[ i ] ) ; 


| 
// Xt EHCI 使 能 ,主要 是 时 钟 等 的 控 肯 
ret = omap. start, ehe( omap, hed) ; 
if( ret) | 
dev. dbg( &pdev -> dev, "failed to start ehci Wn" ) ; 





= 


goto err_start; 
| 
//EHCI 传输 相关 寄存 器 
omap —> ehci -> regs = hed —> regs 


+ HC LENGTH( readl( &omap -> ehci -> caps -> he, capbase) ) ; 


/ * cache this readonly data; minimize chip reads * / 
omap —» ehci -> hes. params = readl( &omap -> ehci -> caps -> hes. params) ; 
// Va] S B s DIL E e 
ret = usb. add. hed(hed, irq, IRQF_DISABLED | IRQF_SHARED) ; 
if( ret) | 
dev. dbg( &pdev -> dev, "failed to add hed with err % d\n", ret); 
goto err add hcd; 





/ * root ports should always stay powered * / 
ehci port. power( omap -> ehci, 1) ; 


return 0; 











从 分 析 中 可 见 ， 主 要 的 工作 是 进行 属性 的 设置 、 资 源 的 申请 和 接口 的 注册 ， 然 后 通过 usb 
add_hed 的 调用 实现 功能 。 

相应 的 platform device 是 在 系统 初始 化 时 通过 usb_ehci_init 进行 的 ， 这 里 就 不 进行 详 
述 了 。 

2. 总线 传 输 

总 线 传输 的 控制 融 接 口 是 由 he, driver 来 定义 的 ，DM 3730 ehci 相关 的 功能 由 ehci_omap_hc_ 
driver 来 实现 ， 具 体 细 节 如 下 : 
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static const struct hc, driver ehci_omap_hc_driver = | 





. description = hed. name, 

. product, desc =" OMAP - EHCI Host Controller" , 
. hed. priv, size = sizeof( struct ehci_hcd), 

// 总 线 控制 器 中 断 操作 

. irq = ehci irq, 

. flags - HCD MEMORY | HCD USB2, 


// 总 线 控制 器 生命 周期 的 操作 








. reset =ehci_init, 
. start = ehci, run, 
. Stop = ehci, stop, 
. shutdown = ehci, shutdown, 


// 管 理 IO requests 和 相关 的 资源 








. urb_enqueue = ehci_urb_enqueue, 

. urb_dequeue = ehci_urb_dequeue, 

. endpoint_disable = ehci_endpoint_disable, 

. endpoint_reset = ehci, endpoint, reset, 

// 调 度 的 支持 

. get_frame_number = ehci_get_frame, 

//root hub 相关 操作 

. hub_status_data = ehci_hub_status_data, 

. hub_control = ehci_hub_control , 
#ifdef CONFIG PM 

. bus, suspend = ehci omap. bus, suspend, 

. bus resume = ehci, omap. bus, resume, 
#endif 

. relinquish_port = NULL, 

. port_handed_over = ehci_omap_port_handed_over, 


. clear tt. buffer complete = ehci_clear_tt_buffer_complete , 
. recover. hed = ehci omap recover work, 


| 





从 中 可 见 ， 主 要 的 接口 都 是 标准 的 EHCI 操作 接口 。Linux 内 核 为 各 种 USB 总 线 控制 器 
开发 了 标准 的 操作 接口 ，EHCI 同样 提供 了 统一 的 操作 接口 。EHCI 总 线 控制 器 整体 架构 如 
图 7-18 所 示 。 图 7-18 引 自 《EHCI 规范 》。 

从 图 7-18 中 可 见 ，EHCI 将 传输 分 为 periodic 和 asynchronous 两 个 调度 队列 ， 中 断 和 周 


期 传输 使 用 periodic 调度 ， 而 其 他 传输 使 用 asynchronous 队列 。EHCI 的 调度 和 传输 都 是 





ehci - q. c 和 ehci - sched. c 来 实现 的 。 
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图 7-18 EHCI USB 总 线 控制 器 整体 框图 





EHCI 控制 器 实现 原理 : 处 理 器 需要 把 1SO 数据 和 INT 数据 建立 一 张 表 放 在 内 存 中 ， 而 
ECHI 的 寄存 器 FRINDEX 则 会 跟踪 这 个 表 ， 每 一 个 时 间 片 加 1，FRINDEX 所 指 之 处 ， 控 制 
器 就 会 把 这 个 指针 所 指向 的 数据 结构 中 的 数据 送 到 总 线 上 去 。 除 了 周期 调度 EHCI 控制 器 
外 ， 还 提 拱 了 另 一 种 调度 来 处 理 实 时 性 要 求 不 高 的 数据 ， 叫 做 异步 调度 。 处 理 器 把 块 传输 和 
控制 传输 的 数据 按 协 议 要 求 的 数据 结构 在 内 存 中 安排 并 建立 一 个 链表 ，AsyncListAddr 则 会 
跟踪 这 个 链表 ， 总 线 控制 器 则 把 AsyncListAddr 所 指向 的 数据 搬运 到 USB 总 线 上 去 。 

EHCI 的 实现 都 是 按照 EHCI 控制 器 规范 来 做 的 ， 其 中 涉及 很 多 EHCI 规范 的 内 容 ， 这 里 
就 不 进行 详细 分 析 了 。 


7.4.4 USB 总 线 驱 动 电源 管理 相关 说 明 


关于 USB 整体 的 电源 管理 ， 首 先 来 看 总 线 部 分 ， 在 usb. bus type 中 与 电源 管理 相关 的 
操作 接口 如 下 : 








static const struct dev_pm_ops usb_bus_pm_ops = | 





. runtime_suspend = usb_runtime_suspend, 
. runtime_resume = usb. runtime, resume, 
. runtime. idle = usb. runtime, idle, 


i? 





以 usb. suspend, both 为 例 ， 其 中 会 通过 usb, suspend. both XJ usb. interface 和 usb. device 进 
f$ suspend 操作 ， 这 样 就 会 执行 驱动 对 应 的 suspend BRE, usb device 相应 操作 由 generic_ 
suspend 来 实现 ， 细 节 如 下 : 


static int generic_suspend( struct usb_device * udev, pm_message_t msg) 


| 


int re; 
// 若 是 root hub 则 总 线 suspend 
if( | udev —> parent) 
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rc = hed_bus_suspend( udev, msg); 

else if( msg. event == PM_EVENT_FREEZE | | msg. event == PM_EVENT_PRETHAW ) 
rc =0; 

else 


re = usb. port, suspend(udev, msg) ; 


return rc; 


| 


可 见 相 应 设备 根据 是 否 为 root hub 进行 适合 的 操作 。 
以 上 是 runtime pm 的 操作 ， 而 对 于 SLM 相关 操作 ， 则 是 由 usb, device. type 来 实现 的 ， 
相应 的 接口 是 usb_device_pm_ops: 





static const struct dev_pm_ops usb_device_pm_ops = | 


. prepare = usb. dev. prepare, 

. complete = usb. dev. complete, 
. suspend = usb. dev. suspend, 

. resume = usb. dev. resume, 

. freeze = usb. dev. freeze, 

. thaw = usb. dev. thaw, 

. poweroff — usb. dev. poweroff, 
. restore — usb. dev. restore , 


E 
对 于 总 线 控制 器 的 电源 管理 操作 ， 以 DM 3730 ECHI 为 例 ， 主 要 操作 接口 如 下 : 





static const struct dev. pm. ops ehci_omap_dev_pm_ops = | 
. suspend =ehci omap. dev, suspend, 
. resume. noirq = ehci, omap. dev, resume, 


F 


这 里 主要 是 对 控制 需 进 行 enable 和 disable 操作 。 

另外 USB 总 线 的 电源 管理 操作 会 调用 he. driver 的 电源 管理 操作 接口 ， 在 DM 3730 EHCI 
控制 器 中 是 由 ehci_omap_bus_suspend 和 ehci_omap_bus_resume 来 实现 的 ， 以 suspend 操作 
为 例 : 


static int ehci_omap_bus_suspend( struct usb_hcd * hed) 


| 
struct usb_bus * bus = hed_to_bus(hed) ; 
int ret; 
// 停 止 总 线 操 作 ,进行 相关 remote wakeup 设置 
ret = ehci_bus_suspend( hed) ; 
// AER Ti i ae suspend 操作 
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ehci_omap_dev_suspend( bus -> controller) ; 


return ret; 


| 
这 样 USB 总 线 的 电源 管理 部 分 就 基本 就 完整 了 








7.5 小 结 
本 章 主要 介绍 各 种 总 线 型 设备 驱动 ， 各 种 驱动 会 根据 总 线 的 特点 进行 设计 ， 并 尽量 为 功 


良好 的 界面 ， 方 便 驱动 以 及 应 用 程序 的 开发 。 
思想 ， 是 值得 用 心 学 习 的 部 分 。 


能 层 及 应 用 层 提供 
总 线 型 驱动 各 具 特 色 ， 其 中 框架 设计 也 包含 了 很 多 设计 
这 里 以 层次 的 方式 ,将 整体 的 框架 从 针对 应 用 的 上 层 到 总 线 设 备 操作 的 下 层 进行 完整 分 析 。 


自 上 而 下 打通 时 ， 整 个 框架 就 被 比较 清晰 地 展现 了 。 





TN 9 
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第 8 竟 设备 驱动 乙 SoC 特殊 驱动 


8.1 SoC 电源 管理 核心 技术 详解 


8.1.1 SoC 电源 管理 需求 


SoC 处 理 器 中 包含 各 种 各 样 的 设备 功能 模块 ， 设 计 良 好 的 电源 管理 设备 需要 能 对 每 个 模 
块 单独 进行 管理 ， 人 允许 对 这 些 功能 模块 进行 单独 的 开关 操作 。 并 且 需 要 与 系统 的 电源 管理 功 
能 结合 ， 完 成 整体 的 电源 管理 功能 。 

KAZ, SoC 电源 管理 既 要 满足 系统 的 整体 需求 ， 又 要 满足 功能 模块 的 单独 需求 ， 做 到 兼 
顾 整体 和 个 体 。 


8.1.2 TI 芯片 Soc 电源 管理 相关 实现 详解 


SoC 电源 管理 框架 与 SoC 的 设计 息息相关 。Linux 内 核 在 设备 模型 中 提供 了 platform 总 线 
来 关联 SoC 中 的 各 个 子 模块 ， 这 样 就 可 以 利用 platform 总 线 框架 实现 SoC 电源 管理 的 功能 。 
platform 总 线 相 关 的 电源 管理 功能 已 经 在 设备 模型 部 分 进行 了 介绍 。 接 下 来 主要 以 DM 3730 
为 例 对 TI 芯片 SoC 电源 管理 实现 进行 介绍 。 

DM 3730 SoC 电源 管理 整体 框架 如 图 8-1 所 示 。 

从 图 8-1 可 见 ，DM 3730 SoC 电源 管理 的 核心 是 omap_device， 其 中 包含 了 platform_de- 
vice 和 hwmod ，platform_device 部 分 包含 了 与 platform bus 相关 的 部 分 ， 而 hwmod 包含 了 DM 
3730 中 各 个 控制 器 的 硬件 信息 〈 如 时 钟 、 中 断 、DMA 和 片 内 总 线 的 关联 ) 。 这 样 就 将 系统 
框架 的 platform 设备 到 具体 芯片 内 部 控制 器 的 信息 关联 起 来 ， 再 与 具体 的 操作 结合 就 可 以 实 
现 电源 管理 功能 。 

关于 初始 化 阶段 如 何 将 DM3730 电源 管理 功能 与 platform bus 以 及 设备 模型 结合 可 以 参 
见 图 8-2。 

从 图 8-2 中 可 见 ， 在 各 个 模块 的 init 操作 中 通过 omap_device_build 来 读 取 hwmod 
的 信息 并 创建 相关 实体 和 platform device， 从 而 与 设备 模型 结合 ， 这 样 在 整个 框架 上 ， 
就 完整 了 。 

platform device 的 电源 管理 操作 会 涉及 platform bus。 下 面 来 看 看 DM3730 做 了 什么 
处 理 : 




















//DPM, runtime pm 的 接口 注册 初始 化 程序 
static int __init omap_pm_runtime_init( void) 
| 

const struct dev_pm_ops * pm; 


struct dev_pm_ops * omap_pm; 
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resource [| 
pdev archdata hwmod(DISPC) 
pdev machdata hwmodRFBI) 
hwmod(VENO) 
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8-1  DM3730 SoC 电源 管理 整体 架构 














// 获 得 platform bus 的 pm 操作 接口 
pm = platform, bus. get. pm. ops( ) ; 
if( ! pm) | 
pr err(" 46s; unable to get dev. pm. ops from platform. bus Wn" , 
. fune ); 


return - ENODEV ; 


// 复 制 所 有 platform, bus 的 pm 接口 
omap. pm = kmemdup( pm, sizeof( struct dev pm ops) , GFP_KERNEL) ; 





if( ! omap. pm) | 
pr. err(" 46s; unable to alloc memory for new dev. pm, ops Wi" , 


. fune ); 
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kernel init) do_basicsetup() do initials() device driver 


omap_device_build(od) —— platform device. register(pdev ) 


device _initialize() platform_device_add (pdev) 


device_add(dev) 





I W 
42 b 
[78 »4T7 79. »4 
dmtimer umm dmtin er.0 a 


dmtin er.1 


8-2 DM3730 SoC 电源 管理 初始 化 阶段 架构 


return - ENOMEM ; 


/修改 需要 修改 的 接口 

omap. pm -> runtime. suspend = omap_pm_runtime_suspend; 
omap. pm —» runtime, resume = omap. pm runtime resume; 
omap. pm -> suspend. noirq = omap. pm. suspend. noirq; 


omap. pm —> resume noirq = omap pm resume, noirq; 





// 注 册 回 调 保证 porting 为 合适 的 omap. pm 接口 


platform bus set pm ops(omap. pm) ; 


return 0; 


可 见 其 修改 了 platform bus 电源 管理 操作 的 部 分 接口 ， 以 omap. pm. runtime, suspend 和 
omap_pm_suspend_noird 为 例 看 看 具体 的 操作 : 


//RRBHN runtime power 管理 的 具体 device 的 suspend 接口 。 在 omap 中 device 
VLR omap_device 


static int omap_pm_runtime_suspend( struct device * dev) 
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struct platform device * pdev = to. platform, device( dev) ; 
int r, ret 20; 


fune ); 


£o 


dev. dbg( dev, "96 s Wn" 


// 首 先 执行 标准 的 runtime suspend 操作 ,需要 device 相应 的 driver 
// 提 供 runtime 的 接口 


ret = pm_generic_runtime_suspend( dev) ; 














if( | ret && dev -> parent == &omap_device_parent) | 
//omap_device 在 build 都 会 赋值 parent 为 omap_device_parent 
// 这 里 调用 plat_omap 的 omap_device 的 idle 接口 ,最终 
// 调 用 omap_hwmod 的 idle 接口 , disable clock ,并 使 module 进入 idle 
r = omap_device_idle( pdev) ; 


WARN_ON(r) ; 























return ret; 


E 


// 在 系统 进入 suspend 时 会 调用 suspend, devices and. enter, 先是 调用 dpm. suspend, 
// 使 得 driver 的 suspend 被 调用 ,为 驱动 级 别 的 suspend ; 接着 调用 dpm_suspend_noirq ， 
// 使 得 bus 的 pm 中 的 suspend_noirg 被 调用 ,为 hwmod 级 别 的 suspend 

int omap. pm. suspend. noirq( struct device * dev) 


| 





struct device driver * drv = dev —> driver; 


int ret 20; 


if( ! drv) 


return 0; 


// 如 果 有 调用 驱动 的 相关 函数 
if(drv -> pm) | 





if( drv -> pm —> suspend. noirq) 
ret = drv —> pm —> suspend. noirq( dev) ; 


Je 
* The DPM core has done a get to prevent runtime PM 
* transitions during system PM. This put is to balance 


* out that get so that this device can now be runtime 
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* suspended. 
*/ 
// 这 里 可 调用 runtime 的 接口 完成 后 续 操 作 ,同步 执行 driver suspend 的 


pm. runtime, put, sync( dev) ; 

















return ret ; 


| 








可 见 主 要 还 是 围绕 omap device 的 操作 来 执行 。 而 omap device 会 调用 omap_device_pm_ 
latency 中 的 操作 ， 细 节 如 下 : 





struct omap_device_pm_latency | 
u32 deactivate_lat; 
u32 deactivate, lat, worst ; 
int( * deactivate, func) (struct omap device * od) ; 
u32 activate, lat; 
u32 activate lat worst; 
int( * activate func) (struct omap. device * od); 
u32 flags; 
E 


这 里 既 包 括 了 操作 也 包括 了 pm QoS 的 内 容 ， 实 现 了 比较 全 的 功能 。 相 应 的 操作 接口 
如 下 : 


int omap_device_idle_hwmods( struct omap_device * od) ; 


int omap_device_enable_hwmods( struct omap_device * od); 


整体 的 电源 管理 初始 化 由 omap3_pm_init 完成 ， 详 细 内 容 如 下 : 


//power management 相关 的 初始 化 处 理 函 数 非常 重要 
static int __init omap3_pm_init( void) 


| 





struct power state * pwrst, * tmp; 
struct clockdomain * neon, clkdm, * per clkdm, * mpu, clkdm, * core, clkdm ; 


int ret ; 


if( ! cpu. is. omap34xx( ) ) 
return - ENODEV ; 





// 首 先 检查 相应 的 errata 


pm. errata, configure( ) ; 














printk( KERN, ERR "Power Management for TI OMAP3. 1n") ; 
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//virtual terminal 可 以 在 suspend 时 创建 新 的 console 
// disable 该 功能 ,通过 vt 的 接口 函数 disable 该 功能 
#ifdef CONFIG_OMAP3_PM_DISABLE_VT_SWITCH 
pm_set_vt_switch(0) ; 
#endif 


/ * XXX prem_setup_regs needs to be before enabling hw 
* supervised mode for powerdomains * / 
// TE enable 每 个 power domain 的 hwsup 功能 之 前 要 初始 化 prem 的 寄存 器 


prem, setup. regs( ) B 





// 做 prem FP Bp Ach P PRU EAT] s 4 
ret = request irq( INT 34XX PRCM MPU IRQ, 





(irq- handler. t) prem. interrupt, handler, 
IRQF. DISABLED, "prem" , NULL); 





if( ret) | 


goto errl ; 


// 对 于 每 个 power domain 执行 setup 初始 化 
ret = pwrdm_for_each( pwrdms_setup, NULL) ; 
if( ret) | 
printk( KERN, ERR " Failed to setup powerdomains \n" ) ; 


goto err2 ; 








// 对 于 每 个 clock domain 执行 setup 初始 化 
(void) clkdm_for_each( clkdms setup, NULL) ; 








mpu, pwrdm = pwrdm. lookup( " mpu, pwrdm" ) ; 
if(mpu_pwrdm == NULL) | 
printk( KERN, ERR "Failed to get mpu, pwrdm Wn" ) ; 


goto eri2 ; 


// 记 录 必 要 的 power domain 和 clock domain, 以便 后 续 操 作 
neon, pwrdm = pwrdm, lookup( " neon. pwrdm" ) ; 

per. pwrdm = pwrdm, lookup( " per. pwrdm" ) ; 

core. pwrdm = pwrdm, lookup( " core, pwrdm" ) ; 


cam, pwrdm = pwrdm, lookup( " cam, pwrdm" ) ; 


neon, clkdm = clkdm, lookup( " neon, clkdm" ) ; 
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mpu_clkdm = clkdm_lookup(" mpu_clkdm" ) ; 
per_clkdm = clkdm. lookup( " per. clkdm" ) ; 
core, clkdm = clkdm_lookup( " core, clkdm" ) ; 


// 对 sleep 代码 进行 internal RAM 的 加 载 


omap. push. sram. idle( ) ; 


// 注 册 ldm suspend 的 操作 接口 


suspend set ops(omap. pm. ops) ; 


// 临 时 system idle 的 hook 注册 
// Ja omap3. idle, init 中 对 cpuidle device 注册 时 会 再 次 通过 
//cpuidle_install_idle_handler 注册 该 system idle 的 hook Ef] pm. idle 
































pm_idle = omap3_pm_idle; 
omap3. idle, init( ) ; 


/* 
* RTA is disabled during initialization as per erratum 1608 
* itis safer to disable RTA by the bootloader, but we would like 
* to be doubly sure here and prevent any mishaps 
*/ 
// 根 据 勘误 ,omap3630 要 disable memory 的 retention till access 的 功能 
// 避 免 deepsleep 有 问题 
if(IS PM34XX, ERRATUM( PM. RTA, ERRATUM, i608) ) 
omap3630. ctrl. disable rta( ) ; 


// Y neon 加 MPU 的 依赖 ,这 样 neon 可 以 依赖 于 MPU 进入 不 同 的 状态 
clkdm_add_wkdep(neon_clkdm, mpu_clkdm) ; 


// 如 果 security chip ,初始 化 的 时 候 保护 相应 的 secure ram 的 上 下 文 
if( omap. type( ) ! = OMAP2_DEVICE_TYPE_GP) | 





omap3. secure ram. storage = 
kmalloc(0x803F, GFP. KERNEL) ; 
if( ! omap3, secure, ram, storage) 
printk( KERN. ERR " Memory allocation failed when" 


"allocating for secure sram context n" ) ; 


local irq. disable( ) ; 
local fiq- disable( ) ; 


omap. dma, global context, save( ) ; 





omap3. save. secure, ram, context( ) ; 


omap_dma_global_context_restore() ; 





local irq. enable( ) ; 


local fiq- enable( ) ; 











// XI pm debug 信息 ,关于 寄存 器 的 信息 进行 初始 化 
pm_dbg_regset_init(1) ; 
pm_dbg_regset_init(2) ; 




















// 重 要 scratchpad memory 的 内 容 保存 ,以 便 deep sleep 后 从 系统 恢复 时 用 
omap3_save_scratchpad_contents() ; 
errl ; 
return ret; 
em: 
// 如 果 错 误 则 释放 prom 中 断 及 power state 
free_irq( INT_34XX_PRCM_MPU_IRQ, NULL); 


list_for_each_entry_safe( pwrst, tmp, &pwrst_list, node) | 











list_del( &pwrst —» node) ; 
kfree( pwrst) ; 
} 


return ret; 


这 里 除了 信息 加 载 外 ， 最 重要 的 就 是 调用 omap_push_sram_idle 与 操作 suspend_set_ops 
(omap_pm_ops) omap_push_sram_idle 是 将 系统 进入 待机 状态 的 最 后 操作 以 及 从 待机 状态 恢 
复 的 开始 操作 的 代码 放 入 片 内 RAM 中 ， 这 样 才 能 保证 系统 正确 进入 低 功 耗 状 态 并 且 能 正确 
恢复 ;而 suspend_set_ops( omap_pm_ops) 是 修改 系统 设备 模型 中 SLM 整体 进入 待机 状态 的 操 
作 接 口 ， 详 细 内 容 如 下 : 














// 该 接口 为 omap3 针对 Idm suspend 提供 的 ops 接口 ,使 系统 可 以 进入 相应 的 suspend 
// 状 态 ,目前 支持 suspend 的 只 有 STANDBY 和 MEM 状态 
static const struct platform_suspend_ops omap. pm ops[ ] = | 


| 








. begin -omap3 pm. begin, 

. end = omap3. pm, end, 

. enter = omap3 pm, enter, 

. valid = suspend. valid. only. mem, 


l; 








在 omap3_pm_enter 中 会 通过 omap3_pm_suspend 来 完成 最 后 的 操作 ， 细 节 如 下 : 
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// ZAZU Idm suspend 的 hook 接口 之 一 提供 进入 suspend 实际 操作 接口 
static int omap3_pm_suspend( void ) 


| 


struct power_state * pwrst; 


int state, ret 20; 


// 如 果 需 要 timer 唤醒 则 设置 


if( wakeup_timer_seconds || wakeup_timer_milliseconds ) 





omap2_pm_wakeup_on_timer( wakeup_timer_seconds , 


wakeup_timer_milliseconds ) ; 


/ * Read current next, pwrsts * / 
// 读 取 每 个 power domain 的 当前 状态 以 便 恢复 
list_for_each_entry( pwrst, &pwrst_list, node) 








pwrst —» saved state = pwrdm read next pwrst( pwrst -> pwrdm ) ; 
/ * Set ones wanted by suspend * / 
list. for each, entry( pwrst, &pwrst, list, node) | 

// 设 置 每 个 power domain 要 进入 的 state 

if( omap. set, pwrdm. state( pwrst -> pwrdm, pwrst -> next, state) ) 

goto restore ; 
//clear powerdomain 的 pre power state 以 准备 sleep 
if( pwrdm, clear all prev. pwrst( pwrst -> pwrdm) ) 


goto restore ; 


//uart prepare suspend 
omap. uart, prepare suspend( ) ; 
// 清 除 pending 的 irq ,使 系统 进入 sleep 模式 


omap3_intc_suspend( ) ; 


// 系 统 真正 进入 sleep 的 idle 操作 实现 


omap. sram, idle( ) ; 


restore : 
/ * Restore next pwrsts * / 
// 到 这 里 系统 已 经 恢复 ,需要 做 必要 的 检查 
list_for_each_entry( pwrst, &pwrst_list, node) | 
// 读 取 pre power state, 以 清楚 power domain 从 哪个 state 被 唤醒 


state = pwrdm_read_prev_pwrst( pwrst 一 > pwrdm) ; 








if( state > pwrst — > next. state) | 
// Wi RB pre power state 比 想 要 进入 的 power state K, 
// 说 明 没 有 能 进入 希望 的 state, 输 出 log, 以 引起 注意 
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printk( KERN, INFO " Powerdomain( 96s) didn t enter " 
"target state % d\n", 
pwrst —» pwrdm —» name, pwrst —» next, state) ; 
ret - -1; 


| 

// 恢 复 power domain 进入 sleep 之 前 的 state 

omap_set_pwrdm_state( pwrst —> pwrdm, pwrst —>saved_state) ; 
} 
if( ret) 

printk( KERN_ERR "Could not enter target state in pm_suspend\n" ) ; 
else 

printk( KERN_INFO "Successfully put all powerdomains " 


"to target state Wn" ) ; 


return ret ; 


| 


至 此 ， 对 DM3730 芯片 电源 管理 整体 实现 进行 了 完整 说 明 。 该 架构 整体 比较 清晰 ， 将 共 
性 的 部 分 做 了 完整 抽象 ， 从 而 简化 了 各 个 功能 模块 的 实现 过 程 。 

该 框架 可 以 在 DM 3730 中 使 用 ，TI 的 其 他 系列 芯片 (包括 DM8IXX 和 Sitara 系列 ) 也 
都 可 以 使 用 该 架构 实现 电源 管理 功能 。 


8.2 小 结 


本 章 针对 SoC 电源 管理 技术 展开 ， 主 要 介绍 了 DM3730 SoC 电源 管理 的 设计 与 实现 。 电 
源 管 理 技术 是 一 个 复杂 的 工程 ， 需 要 考虑 从 设备 到 内 部 模块 ， 从 整体 功能 到 个 体 功能 的 各 个 
部 分 。 要 设计 一 个 良好 的 SoC 电源 管理 架构 ， 就 要 从 内 核 的 整体 需求 出 发 ， 将 片 内 各 个 模块 
的 共性 抽象 形成 统一 的 管理 实体 ， 再 与 具体 的 芯片 操作 结合 ， 从 而 形成 良好 的 设计 。 在 这 些 
方面 ， 开 芯片 〈 特 别 是 DM3730) 做 了 很 多 创造 性 的 工作 ， 值 得 学 习 、 研 究 。 
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